Amazon Web Services ブログ

AWS データストア内の機密データを保護するためのベストプラクティス

クラウド内の機密データを保護するための効果的な戦略を立てるには、一般的なデータセキュリティパターンをよく理解し、これらのパターンを明確にマッピングしてクラウドセキュリティコントロールに活かすことが必要です。その後、これらのコントロールを Amazon Relational Database Service (Amazon RDS) や Amazon DynamoDB などのデータストアに固有の実装レベルの詳細に適用できます。

このブログ記事では、データを保護する一般的なデータセキュリティパターンとそれに対応する AWS セキュリティコントロールに焦点を当てます。この記事では Amazon RDS と DynamoDB について説明しますが、Amazon RDS と DynamoDB の実装については、今後投稿する 2 つの記事で詳細に説明する予定です。

AWS クラウド導入フレームワーク

AWS クラウド導入フレームワーク (AWS CAF) は、組織全体でクラウドコンピューティングへの包括的なアプローチを構築するのに役立つガイダンスとベストプラクティスを提供します。このフレームワーク中、AWS CAF のSecurity Perspective は主に次の 5 つの機能をカバーしています。

  1. AWS Identity and Access Management (IAM): AWS のサービス、アクション、およびリソースにわたるユーザーのアクセス許可を定義、実施、監査します。
  2. 発見的コントロール: セキュリティに対する姿勢を改善し、環境のリスクプロファイルを縮小し、問題がビジネスに影響を与える前に問題を発見するために必要な可視性をもたらします。
  3. インフラストラクチャセキュリティ: 管理するインフラストラクチャの表面積を減らし、AWS 上のインフラストラクチャ全体のプライバシーと管理を強化します。
  4. データ保護:ネイティブに統合された暗号化サービスを使用して、送信中および保存時のデータを保護するのに役立つ適切な保護手段を実装します。
  5. インシデント対応: セキュリティ計画のガイドとして、セキュリティインシデントへの対応を定義して実行します。

AWS CAF の Security Perspective からセキュリティを実装する際の最初のステップは、データの観点からセキュリティについて考えることです。

オンプレミスとオフプレミスのデータセキュリティについて考えるのではなく、保護しているデータ、その保存方法、およびそれへのアクセス権限がある人は誰かについて考えてください。次の 3 つのカテゴリーは、データの観点からセキュリティについて考えるのに役立ちます。

  1. データの分類とセキュリティゾーンのモデル化。
  2. 徹底的な防御。
  3. スイムレーンの隔離。

この記事の残りの部分では、これらの各カテゴリーについて詳しく説明していきます。

データの分類とセキュリティゾーンモデリング

データの分類

すべてのデータが等しく作成されるわけではありません。つまり、データを正しく分類することがそのセキュリティにとって非常に重要です。この分類プロセスの一環として、厳格なセキュリティ体制と柔軟なアジャイル環境の間の複雑なトレードオフに対応するのは困難になりえます。

長いアクセス制御手順を必要とする厳格なセキュリティ体制を敷くことで、データセキュリティについてより強力な保証が得られます。ただし、このようなセキュリティ体制は、開発者がデータストアへのセルフサービスアクセスを必要とする、機敏でペースの速い開発環境では逆効果です。データ分類の仕方を考える際は、広範囲のアクセス要件を満たすようにします。

ほとんどの場合、データを分類する方法はパブリックやプライベートのようにバイナリである必要はないので、データ分類モデルに適切なレベルの忠実度を追加します。次の図に示すように、データの機密レベルはさまざまで、各レベルの機密性と極秘性に該当するデータを保有している可能性があります。予防的コントロールと発見的コントロールを適切に組み合わせてデータセキュリティコントロールを設計することで、データの機密性に適切に見合うようにします。

セキュリティゾーンモデリング

データセキュリティに関するもう 1 つの観点は、データにアクセスする方法と場所を検討することです。セキュリティゾーンは明確に定義されたネットワーク境界を示し、コントロールを実装してネットワーク内部のすべての資産を保護します。セキュリティゾーンはまた、明確さと推論の容易さをもたらし、特性に基づいてセキュリティゾーンに出入りするネットワークフローの制御方法を定義し、実施します。

たとえば、機密データを保持するすべての資産は、セキュアゾーンにまとめることができるかもしれません。セキュアゾーン上に、他のセキュリティゾーンの階層型ネットワークフローコントロールアーキテクチャを作成することができます。たとえば、アプリケーションロジック資産用の制限付きゾーン、インターネット向け資産用の外部ゾーンがあります。補完的な IAM ポリシーと組み合わせて、AWS ネットワークアクセスコントロールリスト (ACL) を介したネットワークフローコントロールポリシーを定義できます。これにより、セキュアゾーンへのアクセスを制限付きゾーンからのアクセスのみに限定し、インターネット向け外部ゾーンからは行えないようにします。このアプローチでは、次の図に示すように、機密データをインターネットのアクセシビリティ下にある 2 つのセキュリティレイヤーに配置します。

データ分類モデルと組み合わせると、セキュリティゾーンモデリングはデータアクセスポリシーを多面的にすることができます。データの分類により、データに適切なセキュリティゾーンを定義できます。セキュリティゾーンにより、データに対して適切なレベルのネットワークフローコントロールとアクセスポリシーコントロールを適用する柔軟性が得られます。

徹底的な防御

徹底的な防御の概念は、単一のセキュリティコントロールが失敗した場合に冗長性を提供するために、複数のセキュリティコントロールをまとめて階層化することを指しています。徹底的な防御が行えるようにするために、次の 2 つのカテゴリーのセキュリティコントロールをシステムに適用できます。

  • 予防的:  このコントロールには、IAM の AWS CAF の Security Perspective 機能、インフラストラクチャセキュリティ、およびデータ保護が含まれます。
  • 発見的:このコントロールは設定の変更や望ましくない行動を発見し、インシデント対応を適時に行えるようにします。発見的コントロールと予防的コントロールを組み合わせることで、総合的なセキュリティ体制を整えます。

効果的なセキュリティ体制では、ビジネスおよびテクノロジーの展望は動的かつ進化的であるため、予防的セキュリティコントロールと発見的セキュリティコントロールの両方が必要となります。

予防的コントロール

予防的コントロールには、主に次の 3 つのカテゴリーに階層化できます。

  • IAM
  • インフラストラクチャセキュリティ
  • データ保護 (暗号化とトークン化)

コントロールを階層化する順序は、ユースケースによって異なります。たとえば、IAM コントロールは、データベースレイヤーまたはユーザーアクティビティの開始時、あるいはその両方に適用できます。次の図は、メンタルモデルを提示するために、データへの安全なアクセスを支援するためにコントロールを階層化する方法の 1 つを示しています。

これらの各コントロール層を詳細に見てみましょう。

DDOS 保護: 分散型サービス妨害 (DDOS) 攻撃は、アプリケーションを通じてデータベースに負担をかけてしまう可能性があります。AWS Shield などのサービスと Amazon CloudFront などのコンテンツ配信ネットワークサービスを組み合わせて使用することで、アプリケーションとデータベースをレイヤー 3 とレイヤー 4 のボリューム攻撃から保護するのに役立ちます。詳細については、「AWS Best Practices for DDOS resiliency」をご覧ください。

ネットワークの隔離: データベースを保護するための最も基本的な方法の 1 つに、データベースを Virtual Private Cloud (VPC) に配置するか、VPC エンドポイントを介して VPC からのみアクセスできるようにすることがあります。これは DynamoDB や Amazon S3 などのリージョンサービスに適用されます。

どちらの場合も、データベースとの間のトラフィックはネットワーク内に留まり、外部には公開されません。その結果、データベースへのアクセスを VPC の内部リソースに制限することができます。これにより、データベースへのきめ細かなネットワークアクセスコントロールをより簡単に実装できます。

アプリケーションレイヤーの脅威防止: このレイヤーは、アプリケーションレイヤーを介して間接的にデータベースに適用されます。ポイントは、ウィーケストリンクのセキュリティレベルと同じレベルのセキュリティしかないという点です。アプリケーションはデータベースへの「フロントドア」アクセス権を持っているので、SQL インジェクションなどの脅威からアプリケーションを確実に保護する必要があります。

Application Load Balancer または CloudFront ディストリビューションで AWS WAF を有効にすることで、このような脅威からアプリケーションを保護してください。これは、SQL インジェクションや OWASP Top 10 のアプリケーション脆弱性などのアプリケーションレベルの攻撃を軽減するのに役立ちます。また、AWS Marketplace から入手できるようなデータベースファイアウォールアプリケーションソリューションを有効にすることもできます。

セキュリティグループとネットワーク ACL: データベースへのネットワークトラフィックを制限することで、データベースへの正当なトラフィックのみが許可され、その他のすべてのトラフィックは確実にブロックされるようにして、攻撃ベクトルを減らすことができます。ネットワーク ACL を使用してゾーンベースモデル (ウェブ/アプリケーション/データベース) を実装し、セキュリティグループを用いてアプリケーションスタックのコンポーネントにマイクロセグメンテーションを行えます。セキュリティゾーンモデリングの詳細については、AWS Security Best Practices ホワイトペーパーの「Using Security Zoning and Network Segmentation」のセクションをご覧ください。

各アプリケーションにセキュリティグループを設定することで、選択したアプリケーションセキュリティグループからの入力トラフィックのみを許可するようにセキュリティグループを設定して、データベースのネットワークセキュリティをモデル化できます。このアプローチでは、アプリケーション Classless Inter-Domain Routing (CIDR) の範囲を使用してデータベースのネットワークセキュリティを管理する必要があるという複雑さも解消されます。セキュリティグループを設定する方法の詳細については、「Working with Security Groups」をご覧ください。

Identity and Access Management (IAM): 認証のための強力で柔軟なメカニズムを有効にするには、アプリケーションフロー (データへのアプリケーションアクセス) から管理フロー (データベース管理タスク) を分離します。管理フローについては、IAM を使用し、認証と承認に多要素認証を実装することを検討してください。次のコード例は、限定された一連の管理機能を有効にした、IAM ユーザー、グループ、またはロールにアタッチできる Amazon RDS の IAM ポリシーです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LimitedAdmin",
            "Effect": "Allow",
            "Action": [
                "rds:CreateDBSnapshot",
                "rds:StopDBInstance",
                "rds:StartDBInstance"
            ],
            "Resource": [
                "arn:aws:rds:*:*:snapshot:*",
                "arn:aws:rds:*:123456789012:db:test"
            ]
        },
        {
            "Sid": "DescribeInstances",
            "Effect": "Allow",
            "Action": "rds:DescribeDBInstances",
            "Resource": "*"
        }
    ]
}

アプリケーションフローについては、最小特権の原則を対応するデータベースアクセス資格情報に適用します。

専用ネットワークゾーンからより特権の高い管理フローを実現するために、データベース接続と操作を開始します。ゾーンは管理フローに適していると見なされる必要があり、アプリケーションフローとは異なるものです (この記事で前述したセキュリティゾーンのモデル化を参照)。この方法では、管理者の資格情報と操作がアプリケーションの資格情報と操作から切り離されているため、アプリケーションが侵害された場合に環境が損傷する可能性が制限されます。オプションで、特定のセキュリティゾーンから実行されるデータベースコマンドの種類がそのセキュリティゾーンに適していることを確認するために、AWS Marketplace のデータベースファイアウォールソリューションをポリシー実施ポイントとして実装できます。

データベースに IAM と統合されていない認証情報が必要な場合は、秘密管理システムの使用を検討してください。AWS Secrets Manager や AWS Systems Manager パラメータストアなどのシステムは、安全に保存し、ローテーションし、データベース認証情報のアプリケーションへのランタイムアクセスを許可します。

暗号化とトークン化: データの暗号化とトークン化は、許可されていないアクセスメカニズムによるデータの流出などのリスクから保護するのに役立ちます。保存時と送信中の両方でデータの暗号化を有効にします (Amazon RDS と Amazon DynamoDB でこれを行う方法の詳細については、今後のブログ記事で説明する予定です)。

マスター暗号化キーがどのように生成され、ライフサイクルがどのように管理されるかも考慮してください。暗号化キー管理のシンプルで堅牢なメカニズムは、AWS Key Management Service (AWS KMS) を通じて提供されます。AWS KMS は、AWS KMS で管理されるキーを使用したデータ暗号化に関してカスタマーマスターキー (CMK) をサポートし、さらに Amazon S3、Amazon EMR、Amazon Redshift、Amazon RDS、DynamoDB と統合しています (リージョンサポートを参照)。

AWS KMS で管理される暗号化キーを使用したアプリケーションレベル (クライアントサイドとも呼ばれる) の暗号化を検討してください。ただし、アプリケーションレベルの暗号化を使用するかどうかは、データの一部の高度に保護された分類の有無、エンドツーエンド暗号化の必要性、およびバックエンドインフラストラクチャでエンドツーエンド暗号化をサポートできるかどうかなどの要因によって異なります。このオプションは、データベースがアプリケーション暗号化データに対して実行できるネイティブ機能を制限してしまう可能性があるため、慎重に検討してください。

最後に、トークン化は、機密性の高いデータや PCI などの特定の規制順守要件を持つデータの特定の部分を保護するのに役立つ暗号化の代替手段です。機密データを専用の安全なデータストアに分離し、その代わりにトークンを使用することで、エンドツーエンド暗号化の潜在的なコストと複雑さを回避できます。一時的な使い捨てトークンを使用してリスクを軽減することもできます。

発見的コントロール

発見的コントロールを効果的に適用することで、変更やインシデントに対応するために必要な情報を入手できます。セキュリティ情報およびイベント監視 (SIEM) システムに統合された堅牢な発見メカニズムにより、セキュリティの脆弱性およびデータのセキュリティ体制の継続的な改善に迅速に対応できます。

実装できる発見的コントロールをいくつか詳しく見てみましょう。

不正なトラフィックの検出: VPC フローログを継続的に監視することで、セキュリティの異常を特定して修正することができます。Amazon GuardDuty は、マネージド型脅威インテリジェンスを提供するマネージド型サービスです。GuardDuty は、VPC フローログ、AWS CloudTrail、および DNS ログからフィードを受け取ります。これは、機械学習、パターンベースのシグネチャ、および外部の脅威インテリジェンスソースを使用して、実用的な調査結果を提供します。これらの調査結果を Amazon CloudWatch イベントとして利用して、自動応答を駆動することができます。

設定のドリフト: 設定のドリフトは、システムの現在のセキュリティ設定が理想的な強化状態からずれている状態のことです。設定のドリフトは、最初のデプロイ後にシステムに変更を加えることによって発生する可能性があります。データベースのセキュリティ体制の整合性を確保するためには、設定のドリフトを特定し、報告し、修正する必要があります。AWS Config は DynamoDB と組み合わせて使用することでテーブルレベルの設定のドリフトを簡単に発見し、また Amazon RDS と組み合わせて使用することでデータベースインスタンス、セキュリティグループ、スナップショット、サブネットグループ、およびイベントサブスクリプションの設定のドリフトを検出できます。

きめ細かな監査: データベースへの管理フローとアプリケーションフローの両方で監査を有効にすることを検討してください。データベースアクセスの監査範囲と使用方法については、特定の環境と使用方法に基づいて段階的な微調整が必要になる場合があります。監査にはパフォーマンスのトレードオフがあり、使用するデータベースに応じてさまざまな監査範囲が考えられます。

データベース上のデータベース管理イベントだけでなく、すべての直接データ定義言語 (DDL) およびデータ操作言語 (DML) ステートメントを取り込むことから始めることもできます (特に、運用開始の初期段階で)。使い方が明確になり、セキュリティ設計に自信が持てるようになったら、条件を徐々に絞り込むことができます。

Amazon RDS では、CreateDBInstance、StartDBInstance、StopDBInstance など、CloudTrail を使用して Amazon RDS API へのすべての呼び出しをログに記録できます。さらに、データベースエンジンでサポートされている場合は、個々のデータベース管理システムエンジンの設定主導型 SQL 監査またはシステム監査テーブルを使用して、データベースに対して実行されている SQL クエリを監査できます。今後の記事でこれらについて詳細に説明する予定です。

CloudWatch を使用してリアルタイム Amazon SNS 通知を作成する、AWS Lambda 関数を実行する、発券システムでセキュリティインシデントを作成する、または SIEM システムでイベントをトリガーするといったアラートルールを設定できます。また、CloudTrail がイベントログを CloudWatch に送信するように設定することもできます。Amazon Aurora MySQL、Amazon RDS MySQL、およびMariaDB は、監査済み SQL クエリを含むデータベースインスタンスログイベントを CloudWatch に直接発行できます。

スイムレーンの隔離

スイムレーンの隔離は、ドメイン駆動設計の文脈で最もよく説明できます。ビジネスモデルに似たドメインにマイクロサービスをグループ化することを考えている場合、ビジネスドメインのコンテキストから、それらの各マイクロサービスにアタッチされているデータストアのセキュリティについても考えることができます。これにより、次の 2 つのことが実現できます。

  1. 純粋なマイクロサービスデータアクセスパターンを適用して、マイクロサービスデータストアへのアクセスが、所有するマイクロサービス API を介してのみ行えるようにすること。
  2. あるマイクロサービスドメインからの機密データが別のマイクロサービスドメインを通じて漏洩しないようにすること。

さまざまな機密性と極秘性レベルのデータを API を介して収集、保持、公開する典型的な組織のシナリオを考えてみましょう。たとえば、銀行には、機密性の高いデータを保持する支払いドメインの API 用のデータストアがあります。銀行はまた、マーケティングドメインに、公開されているデータを会社のウェブサイトで開示する API を持っているかもしれません。

さらに、支払いドメインの API は、機密性の低いデータを処理するマーケティングドメインの API と比較して、セキュリティおよび機能上の要件が高い可能性があります。この例では、スイムレーンの隔離により、2 つのドメイン間に厳密なネットワークの分離 (ネットワークスイムレーン) が生まれます。このように、マーケティングドメインで処理されている要求が支払いドメインのデータストアをトラバースして直接アクセスすることはできません。

適切な IAM コントロールとネットワークフローコントロールを適用することで、このスイムレーンの隔離を実現できます。ネットワークフローコントロールには、データストアレイヤーのサブネット全体のネットワーク ACL を含めるか、支払いドメインの VPC エンドポイントからのみデータストアへのアクセスを許可し、発信元からのすべてのトラフィックを拒否します。詳しくは、「VPC Endpoints」と「Network ACLs」をご覧ください。

まとめ

このブログ記事では、AWS 上のデータを保護するためのベストプラクティスと、それらを実装する方法について説明しました。また、AWS CAF と AWS CAF Security Perspective 内の 5 つの主要機能 (AWS IAM、発見的コントロール、インフラストラクチャセキュリティ、データ保護、およびインシデント対応) についても説明しました。

この記事のセキュリティのベストプラクティスは、Security Perspective から見たいくつかの重要な機能に関連しています。これらの機能には、IAM コントロールの定義、データベースに発見的コントロールを実装する複数の方法、ネットワークフローコントロールを介したデータを取り巻くインフラストラクチャセキュリティの強化、および暗号化とトークン化によるデータ保護が含まれます。

データのセキュリティに関するベストプラクティスについて詳しくは、「AWS Security Best Practices」ホワイトペーパーと「Overview of AWS Security – Database Services」ホワイトペーパーをご覧ください。次回のブログ記事では、このブログ記事で説明したデータセキュリティのベストプラクティスの実装について、Amazon RDS の観点から説明する予定です。

 

著者について

Syed Jaffry は、アマゾン ウェブ サービスのソリューションアーキテクトです。彼は、金融サービス業界の顧客と協力して、安全で回復力があり、スケーラブルで高性能なアプリケーションをクラウドに展開するのを支援しています。