英国の組織に対するICOの執行措置は2024年と2025年に急増し、技術的なセキュリティ対策の不備に対して2年間で総額1,200万ポンドを超える罰金が科されました。ICOの執行通知に見られるパターンは一貫しています。侵害を受け、適切な技術的管理を実施していたことを証明できなかった組織が最も厳しい結果に直面しました。開発者にとって、これは直接的な職業上の懸念事項です。暗号化、ログ記録、アクセス制御、データ保持に関して下す判断は、組織がICOの前で自らを守ることができるかどうかを決定する技術的管理です。

このガイドは、法務部門やコンプライアンス部門ではなく、開発者やエンジニアリングチーム向けに書かれています。UK GDPRの要件を具体的な技術的判断に翻訳します。何を実装するか、どのように実装するか、そして各対策がなぜ存在するのか。

要約

  • UK GDPR第32条は、リスクに比例した「適切な技術的措置」を要求しています。個人データを扱うほとんどのアプリケーションでは、保存時と転送時の暗号化、可能な場合の仮名化、アクセス制御、および文書化された侵害検出能力が必要です。
  • GDPRリスクを生み出す最も一般的な開発者のミス：デバッグ出力に個人を特定できる情報（PII）をログ記録すること、削除権のために実際に削除すべきレコードをソフト削除すること、個人データに触れるすべてのサードパーティサービスとDPAを締結しないこと。
  • データ最小化はフィールドレベルで行われる設計上の決定です。フィールドを収集・保存する文書化された理由がない場合は、収集しないでください。
  • 削除権には、バックアップやサードパーティのデータ処理者を含むすべてのシステムを通じた実際の削除が必要です。ソフト削除は義務を満たしません。

UK GDPR vs. EU GDPR：開発者にとって何が変わるか

Brexit後、英国はEuropean Union (Withdrawal) Act 2018を通じてEU GDPRフレームワークを「UK GDPR」として保持しました。開発者にとって、技術的要件は同一です。違いは管理的なものです。英国の監督機関はEUの国内データ保護機関ではなく情報コミッショナーオフィス（ICO）であり、英国とEU間の国境を越えたデータ転送は英国の適切性決定（現在EUが維持していますが、定期的に見直されます）によって規定されています。

実際の意味は、EU GDPRの技術的要件に準拠したソフトウェアを構築すれば、UK GDPRの技術的要件も満たすということです。逆も同様です。乖離が生じるのは通知手続き、転送メカニズム、およびICO固有の執行ガイダンスにおいてであり、これらはEDPBガイダンスとは強調点が異なる場合があります。

第32条：実際に何を要求しているか

UK GDPR第32条は、管理者と処理者に対して、技術の現状、実装コスト、処理の性質・範囲・状況・目的を考慮した上で、リスクに見合ったセキュリティレベルを確保するための「適切な技術的および組織的措置」を実装することを義務付けています。

その文言は意図的に柔軟です。実際に何を意味するかはリスクプロファイルによって異なりますが、第32条(1)には4つの具体的な例が示されています。

  1. 個人データの仮名化および暗号化
  2. 処理システムおよびサービスの機密性、完全性、可用性、回復力の継続的な確保
  3. 物理的または技術的なインシデント後の個人データへのアクセスと利用可能性の適時回復
  4. セキュリティ対策の有効性を定期的にテスト、評価、評価するプロセス

「技術の現状」は、最も高価または最先端のソリューションを実装しなければならないという意味ではありません。明らかにより優れたアプローチ（Argon2など）が確立され、広く利用可能で、実装コストが実質的に高くない場合に、弱いアプローチ（パスワードハッシュにMD5を使用するなど）を使用することを正当化できないという意味です。

保存時の暗号化

パスワード。 パスワードを平文で保存したり、パスワードハッシュにMD5またはSHA-1を使用したりしないでください。どちらも完全に不適切です。少なくともワークファクター12のbcrypt、またはサーバーハードウェアで少なくとも100msかかるように調整されたパラメーターのArgon2idを使用してください。Argon2idはOWASPの現在の推奨であり、新しい実装に適しています。

1# Argon2id with libsodium (Node.js example)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

データベース暗号化。 データベースレベルで保存時の暗号化を有効にします。すべての主要なデータベースおよびマネージドサービス（PostgreSQL、MySQL、MongoDB Atlas、AWS RDS、Azure SQL）がこれをサポートしています。透過的データ暗号化（TDE）はディスク上のデータを保護しますが、クエリアクセス権を持つ侵害されたデータベースユーザーからは保護されません。高度に機密性の高いフィールド（国民保険番号、医療記録、金融口座番号）については、キー管理サービス（AWS KMS、Azure Key Vault、HashiCorp Vault）を使用したAES-256-GCMによるアプリケーションレベルのフィールド暗号化を検討してください。キーは暗号化するデータとは別に保存する必要があります。

キー管理。 アプリケーションコードに暗号化キーをハードコードしたり、保護するデータと同じデータベースに保存したりしないでください。開発にはenv変数を、本番環境にはマネージドキー管理サービスを使用します。定期的にキーをローテーションし、アプリケーションがダウンタイムなしでキーローテーションを処理できることを確認します。

してはいけないこと。 暗号化が適用されない可能性があるログファイル、一時ファイル、またはアプリケーションキャッシュに個人データを平文で保存しないでください。個人データを扱うすべてのコードパスをチェックし、暗号化されていないコピーが不注意に保持されていないことを確認します。

転送時の暗号化

TLS設定。 TLS 1.2を最低限として、サポートされている場合はTLS 1.3をデフォルトとして適用します。SSLv3、TLS 1.0、TLS 1.1を完全に無効にします。nginxの場合：

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS。 長いmax-age値とincludeSubDomainsを指定してStrict-Transport-Securityヘッダーを設定します。少なくとも31536000（1年）のmax-ageが標準です。デプロイが許可する場合は、HSTSプリロードリストに登録します。

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

混在コンテンツ。 HTTPSページからHTTPを通じてリソース（画像、スクリプト、スタイルシート、API呼び出し）を提供すると、混在コンテンツの脆弱性が生じ、転送セキュリティが損なわれます。Content Security Policyを設定して混在コンテンツをブロックし、HTTPS以外のリソースロードがないかページを確認します。

内部サービス。 転送時の暗号化は、ユーザー向けのトラフィックだけでなく、内部サービス間通信にも適用されます。データベース接続、メッセージキュー接続、マイクロサービス呼び出しはすべてTLSを使用する必要があります。多くの開発者はユーザー向けレイヤーを正しく暗号化していますが、内部ネットワークを見落としています。

コードにおけるデータ最小化

データ最小化は法的な抽象概念ではありません。フィールドごとに行われる設計上の決定です。個人データを収集する前に、アプリケーションが機能するためにこれが実際に必要かどうかを確認してください。特定のユースケースでその質問に答えられない場合は、収集しないでください。

実際には次のことを意味します。

  • 任意で目的が曖昧なフォームフィールドを削除する（例：年齢確認要件のないニュースレター登録時の「生年月日」）
  • データベーススキーマを定期的に確認し、使用されていない個人データを含む列を削除する
  • 可能な限りスキーマレベルで保持期間を設定し、スケジュールされたジョブを使用して期限切れのレコードを自動的に削除する
  • アプリケーションが本当に必要としない限り、高い機密性を持つ個人データ（健康情報、財務詳細、政治的見解）の収集を避ける。第32条のリスク評価は処理するデータの機密性に応じてスケールするためです

ICOのアカウンタビリティ原則は、データ最小化を考慮したことを証明できることを要求しています。アーキテクチャやスプリントノートに記録された設計決定はこれを満たします。記録されていない決定は満たしません。

仮名化

仮名化は、直接識別情報を、別途保持されているキーまたはマッピングテーブルにアクセスすることなく個人を特定できないトークンや識別子に置き換えます。第32条はこれを推奨される技術的措置として明示的に列挙しており、第89条は研究目的の仮名化データの処理に対する義務の軽減を規定しています。

分析と行動追跡の場合、分析システムに渡す前にサイト固有のソルトを使用してSHA-256でユーザー識別子をハッシュする一般的なパターンがあります。

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

ソルトは分析データとは別に保存する必要があります。それがなければ、ハッシュを逆算して個人を特定することはできません。これは、分析システムが仮名化された識別子のみを保持することを意味し、そのシステムの侵害のリスクプロファイルを低減します。

仮名化は匿名化ではありません。マッピングキーを保持している場合、ICOは仮名化データを個人データとして扱います。合理的に利用可能な追加情報を持っていても再識別が不可能な完全な匿名化は、データをGDPRの範囲から完全に除外します。実際に真の匿名化を達成することは難しく、ほとんどの実装は依然としてGDPRの対象ではあるが低減されたリスクを持つ仮名化データを生成します。

削除権：適切な実装

削除権（第17条）は、正しく実装するための技術的に最も要求の高いGDPR義務の1つです。要件は具体的です。

物理削除、論理削除ではない。 is_deletedフラグを設定してクエリからフィルタリングすることは、削除権を満たしません。データは実際にデータベースから削除されなければなりません。個人データを保持するすべてのエンティティの物理削除機能を構築します。

カスケード削除。 ユーザーレコードを削除しても、関連テーブル（注文、住所、アクティビティログ、設定、アップロードされたファイル）にも個人データが保持されている場合は不十分です。ユーザー識別子にリンクされた個人データを含むすべてのテーブルをマッピングし、削除が正しくカスケードされるか、すべての関連データをアトミックに削除する明示的な削除ジョブを実装します。

サードパーティのデータ処理者。 個人データをサードパーティサービス（電子メールマーケティングプラットフォーム、CRM、分析ツール、決済処理者）に送信した場合、削除義務はその処理者にデータを削除するよう指示することにまで及びます。これには以下が必要です。

  • 個人データを受け取るすべてのサードパーティサービスの文書化されたインベントリ
  • それぞれの確認済み削除メカニズム（API呼び出し、サポートチケット、自動化されたデータ主体リクエスト処理）
  • 削除が完了したという証拠

バックアップ。 バックアップは最も見落とされがちな削除の問題です。90日間の保持期間で毎日のデータベースバックアップを取得する場合、ライブデータベースで満たされた削除リクエストは、バックアップが期限切れになるまでバックアップでは満たされません。ICOの立場は、削除後に復元されたバックアップが削除された個人データを再導入してはならないというものです。実際的なアプローチには、可能な限り削除されたレコードをバックアップエクスポートから除外すること、バックアップ固有の削除プロセスを実装すること、またはフィールドレベルの暗号化を使用してキーを削除すること（データを読めなくすることで、削除の標準に近づく）が含まれます。

例外。 削除権は絶対的ではありません。法的な主張、法定コンプライアンス（例：会社法に基づく財務記録）、または公益目的に必要なデータを保持できます。例外を文書化し、削除リクエストを拒否または部分的に履行する際に、データ主体に伝えます。

侵害検出と72時間通知要件

UK GDPR第33条は、個人に対してリスクをもたらす可能性が高い個人データ侵害に気づいてから72時間以内にICOに通知することを義務付けています。これは侵害が発生してから72時間ではありません。気づいてから72時間です。この区別は侵害検出能力を構築する直接的なインセンティブを生み出します。なぜなら発見した時から時計が動き始めるからです。

侵害検出のために記録すべきこと。 ログアーキテクチャは以下をキャプチャする必要があります。

  • 認証イベント：成功および失敗したログイン、MFAチャレンジ、パスワードリセット
  • 認可の失敗：権限チェックにより拒否されたリクエスト
  • データアクセス：誰がいつ何の個人データにアクセスしたか、特に一括エクスポートや異常なクエリ量
  • 設定変更：ユーザー権限、暗号化キー、またはデータ保持設定の変更
  • 異常なパターン：異常なIPアドレスからまたは異常な時間帯のアクセス、個人データテーブルの大量読み取り

記録すべきでないこと。 アプリケーションログに個人データの値を記録しないでください。完全なリクエストボディを記録するデバッグログ、パラメータ値が代入されたデータベースクエリ、またはユーザーが入力したフォームデータは、管理が難しく、それ自体がGDPRの対象となる二次的な個人データストアを作成します。値ではなく識別子（ユーザーID、セッションID、リクエストID）を記録します。

1# 間違い：実際のメールアドレスを記録する
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# 正しい：識別子のみを記録する
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

侵害対応計画。 ログ記録は検出を可能にしますが、侵害を検出したときに何が起こるかの文書化されたプロセスが必要です。誰が内部的に通知されますか？誰がICO通知の決定を下しますか？ICO通知には何の情報が含まれている必要がありますか？必要になる前にこのプロセスを構築します。

サードパーティAPIのコンプライアンス

管理者 vs 処理者。 あなたに代わって個人データを処理するサードパーティサービス（トランザクションメールプロバイダー、クラウドインフラプロバイダー、決済処理者）を使用している場合、彼らはデータ処理者であり、あなたは管理者です。その文脈でのUK GDPRへの準拠についてあなたが責任を負います。

データ処理契約。 あなたに代わって個人データを処理するすべてのサードパーティサービスと書面によるデータ処理契約（DPA）を締結する必要があります。ほとんどの主要なSaaSプロバイダー（AWS、Mailchimp、Stripe、Twilio、SendGrid）が標準DPAを提供しています。署名して保管します。プロバイダーがDPAを提供できない場合、UK GDPR下では個人データの処理にそのプロバイダーを合法的に使用することはできません。

サブ処理者。 処理者とのDPAは、そのサブ処理者（データの処理に順番に使用するサービス）をリストアップする必要があります。例えば、トランザクションメールプロバイダーはAWSインフラを使用しているかもしれません。サブ処理者と直接DPAを締結する必要はありませんが、移転コンプライアンスの目的で彼らが誰で、データがどこで地理的に処理されているかを把握する必要があります。

転送メカニズム。 サードパーティサービスが英国またはEU外でデータを処理する場合、法的な転送メカニズムが必要です。英国からの転送については、現在、英国固有のメカニズム（英国の国際データ転送契約、または利用可能な場合は英国の適切性決定への依拠）が必要です。各サービスのデータレジデンシーオプションと転送文書を確認します。

アクセス制御

最小権限の原則。 アプリケーションが使用するデータベースユーザーは、必要最小限の権限（特定のテーブルへの読み書き、管理アクセスなし）を持つべきです。読み取り中心のサービス（レポート、分析）と書き込み中心のサービス（ユーザー向けアプリケーション）には別々のデータベース認証情報を作成します。これにより、侵害された認証情報の影響範囲が制限されます。

ロールベースアクセス制御。 アプリケーションにRBACを実装し、ロール割り当てを定期的に見直します。ロールは時間の経過とともに権限を蓄積する傾向があります。各ロールが実際に必要なものに対する定期的な監査は、権限の増加を検出します。

データアクセスの監査ログ。 機密データについては、どの認証済みユーザーがどの個人データレコードにいつアクセスしたかを記録するアプリケーション層での監査ログを実装します。これはアプリケーションエラーログとは別であり、改ざん防止（書き込み専用または追記専用で、アプリケーションコードからのアクセスが制限されている）である必要があります。

開発者チェックリスト：実装すべき10の技術的管理

  1. パスワードハッシュ。 bcrypt（コストファクター12+）またはArgon2idを使用します。MD5またはSHA-1のパスワードハッシュを直ちに削除します。
  2. 保存時の暗号化。 データベースレベルのTDEを有効にし、マネージドKMSにキーを保持した高機密個人データにフィールドレベルのAES-256-GCM暗号化を実装します。
  3. TLS設定。 TLS 1.2を最低限、TLS 1.3をデフォルト、1年間のmax-ageのHSTS、混在コンテンツなしを適用します。
  4. データ最小化の監査。 個人データを保持するデータベーススキーマのすべてのフィールドを見直します。文書化されたアクティブなユースケースなしにフィールドを削除または収集停止します。
  5. 物理削除の実装。 ユーザーにリンクされたすべての個人データの検証済みカスケード削除を構築します。削除がレコードを実際に削除し、単にフラグを立てるだけでないことをテストします。
  6. サードパーティDPAインベントリ。 個人データを受け取るすべてのSaaSまたはクラウドサービスをリストアップします。各サービスの署名済みDPAの存在を確認します。DPAを提供できないサービスを削除します。
  7. ログ記録の衛生管理。 アプリケーションログでPIIを確認します。すべてのログレベルでログ出力から個人データの値を削除します。識別子のみを記録します。
  8. 侵害検出ログ記録。 認証イベント、認可の失敗、一括データアクセスの構造化ログを実装します。異常なパターンのアラートを設定します。
  9. アクセス制御の見直し。 データベース認証情報とアプリケーションロールを最小権限の原則に照らして監査します。アプリケーションデータベースユーザーから管理アクセスを削除します。
  10. 分析の仮名化。 分析とサードパーティトラッキング呼び出しの直接ユーザー識別子を、サイト固有のシークレットを使用したHMACハッシュ値に置き換えます。

主要なポイント

  • UK GDPRの技術的要件はEU GDPRと同一です。Brexit後、ICOがこれらを執行し、通知と転送についてICO固有のガイダンスに従う必要があります。
  • 第32条はリスクに比例した適切な技術的措置を要求しています。ほとんどのアプリケーションでは、強力な暗号化、アクセス制御、仮名化、および文書化された侵害検出が必要です。
  • データ最小化は、法的な抽象概念ではなく、開発者がフィールドレベルで下す決定です。フィールドの収集を正当化できない場合は、収集しないでください。
  • 削除権には、バックアップとサードパーティのデータ処理者を含むすべてのシステムを通じたカスケード実際の削除が必要です。ソフト削除フラグは義務を満たしません。
  • 個人データの値を記録しないでください。識別子を記録します。ログファイル自体が個人データストアであり、最も見落とされがちな侵害ベクターの1つです。
  • 個人データに触れるすべてのサードパーティサービスと署名済みDPAを持ちます。プロバイダーがDPAを提供できない場合、その目的にそのプロバイダーを合法的に使用することはできません。

よくある質問（FAQ）

すべてのユーザーが英国外にいる場合でもUK GDPRは適用されますか？ UK GDPRは、ユーザーの所在に関わらず、英国に設立されている場合に適用されます。また、英国の人々に商品やサービスを提供したり、英国の人々の行動を監視したりする英国外の組織にも適用されます。非英国オーディエンス向けに構築する英国拠点の開発者の場合、UK GDPRは処理活動に適用されます。

UK GDPRの下で暗号化は必須ですか？ 暗号化は第32条(1)(a)に推奨される措置として明示的に記載されています。規制が「リスクに適切な」措置を要求するため、絶対的な必須要件ではありません。実際には、インターネット上で個人データを扱うアプリケーションでは、転送時と保存時のデータの暗号化を怠ることをICOに正当化することは非常に困難です。必須として扱います。

ICO通知が必要な個人データ侵害とは何ですか？ 個人データ侵害は、個人データの偶発的または不法な破壊、損失、改変、無許可の開示、またはアクセスです。これには、レコードを公開した誤って設定されたS3バケット、顧客データを含むメールアカウントへの攻撃者のアクセスを与えたフィッシング攻撃、バックアップなしのレコードの誤削除が含まれます。すべての侵害がICO通知を必要とするわけではありません。個人に対してリスクをもたらす可能性が高いものだけです。高リスクの侵害には、影響を受けた個人への直接通知も必要です。

個人データはどのくらいの期間保持する必要がありますか？ UK GDPRは保持期間を指定していません。収集された目的のために必要な限り、データのみを保持する必要があります。保持するデータの各カテゴリの保持期間を定義し、プライバシー通知に文書化し、自動削除を実装します。財務記録は通常、会社法に基づいて6年間保持されます。マーケティング同意記録は、同意が撤回または期限切れになるまで保持する必要があります。

データ保護責任者は必要ですか？ DPOは公的機関、大規模に機密性の高い個人データを処理する組織、および大規模な系統的監視を行う組織に義務付けられています。ほとんどの英国ソフトウェア企業では義務ではありませんが、大量の個人データを処理する場合は推奨されます。ICOはこの閾値についてのWebサイトに具体的なガイダンスを提供しています。

UK GDPR非準拠の最大罰金は何ですか？ ICOは最も深刻な違反に対して最大1,750万ポンドまたはグローバル年間売上高の4%（どちらか高い方）の罰金を発行できます。1,750万ポンドを下回る870万ポンドまたはグローバル売上高の2%の下位層の罰金は、それほど深刻でない違反に適用されます。実際には、ほとんどのICO罰金は最大値を大幅に下回り、違反の深刻さ、組織の協力、および問題を是正するために取られた手順に合わせて調整されます。