Amazon Web Services ブログ

Amazon DynamoDB で機密データを保護するためのベストプラクティスの適用



このシリーズの最初の記事であるAWS データストア内の機密データを保護するためのベストプラクティスでは、いくつかの一般的なセキュリティの概念と、AWS データストアに適用できる AWS セキュリティコントロールについて説明しました。これらを使用して、データに関わるセキュリティ体制をより強固にすることができます。2 番目の記事であるAmazon RDS で機密データを保護するためのベストプラクティスの適用では、こうした概念を Amazon RDS データベースで実装する方法を示しました。この 3 番目であり、最後の記事では、これらの概念を Amazon DynamoDB で実装する方法を示します。

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

処理しているデータと処理に関する特定の要件を理解することは重要です。こうした要件は規制であったり、組織の一部として内部的に作成される場合があります。たとえば、この記事で後述するように、データのトークン化などの特殊なセキュリティコントロールの一部は必要ではないかもしれません。常にセキュリティの水準を引き上げようとする必要がありますが、十分に理解してリスクを管理するために適切なコントロールを提供していることも確認してください。

セキュリティゾーンを設計したら、この記事で後述するように、ネットワークアクセスコントロールリスト (ACL) を使用して実装します。この手順では、ネットワークゾーンを粗く定義し、セキュリティグループを使用してこれらのゾーン内でより具体的なマイクロセグメンテーションを許可します。

セキュリティゾーンモデリングを実装するときは、ネットワーク設計を慎重に検討します。CIDR 範囲のサイズによって、各サブネットが表現できる IP アドレスの数が決まります。サブネット内の増加 (より多い IP アドレス) とサブネット数の増加をサポートできるように、CIDR 範囲を設計します。Amazon VPC とオンプレミスのデータセンター間、または VPC 間に矛盾のない IP アドレススペースを確保するための要件とバランスを取ります。詳細については、AWS 単一 VPC の設計を参照してください。

ここで提供されている詳細な説明、およびデータ分類とセキュリティゾーンモデリングの背景にある概念については、AWS データストア内の機密データを保護するためのベストプラクティスを参照してください。

予防的コントロール

次の図はこのシリーズの最初の記事からのもので、防御の概念を詳しく説明しています。コントロールには、予防的コントロールと発見的コントロールの 2 つの主要なカテゴリーがあります。最初に予防的コントロールについて説明しましょう。

DDoS 保護

AWS Shield と連携することで、アプリケーションおよびデータベースを分散サービス拒否 (DDoS) 攻撃から保護することができます。すべての AWS のお客様は、追加料金なしで AWS Shield Standard による自動保護のメリットを受けることができます。AWS Shield Standard は、ウェブサイトやアプリケーションを標的にした、最も一般的で頻繁に発生するネットワークおよびトランスポートレイヤーの攻撃を防御します。AWS Shield Standard を Amazon CloudFront や Amazon Route 53 とともに使用すると、インフラストラクチャ (レイヤー 3 および 4) を標的とするすべての既知の攻撃を総合的に保護できます。

AWS Shield Advanced にサブスクライブすることで、DDoS レスポンスチームと追加のメトリクスにアクセスできます。利用可能な追加の保護の詳細については、AWS Shield の機能を参照してください。

AWS Shield Advanced を有効にするには、以下の手順を実行します。

  1. AWS マネジメントコンソールで、[AWS WAF and AWS Shield] を選択します。

    AWS WAF または AWS Shield Advanced をまだ有効にしていない場合は、ダッシュボードページではなく、次のページが表示されます。
  1. [AWS Shield] を選択します。
    このページには、Standard と Advanced の比較が表示されます。
  1. [Activate AWS Shield Advanced] を選択します。
  1. [Activate service] セクションで、条件に同意するすべてのチェックボックスを選択します。
    .
  2. [Activate service] を選択します。

アプリケーションレベルの脅威の防止

アプリケーションレベルの脅威の防止を支援するには、AWS WAF を使用できます。

使用しているウェブアプリケーションは、データベースに保存されているデータにアクセスする必要があるとします。したがって、Open Web Application Security Project (OWASP) トップ 10 プロジェクトで説明されている攻撃によるデータの漏洩から保護することが重要です。これらの脅威からアプリケーションを保護するように AWS WAF を設定します。AWS WAF は、Amazon CloudFront ではグローバルレベルで動作し、ALB や API Gateway などのリージョンリソースではリージョンレベルでも動作します。

AWS WAF によって OWASP トップ 10 からの保護を開始するには、AWS CloudFormation と owasp_10_base.yml テンプレートを使用してウェブ ACL を作成します。

ネットワークの分離

DynamoDB の機密データに関する重要なセキュリティの考慮事項は、DynamoDB テーブルとの間でのトラフィックのネットワーク分離です。このセキュリティの分離を可能にする基本的な設計要素が、Amazon VPC です。

VPC を作成するには、以下の手順を完了してください。

  1. VPC コンソールを開きます。
  2. [Your VPCs] を選択します。
  3. [Create VPC] を選択します。
  4. [Name tag] では、使用している VPC の名前を選択します。
  5. [IPv4 CIDR block] では、CIDR 範囲を指定します。
  6. IPv6 CIDR ブロックはデフォルト値である「No IPv6 CIDR Block」のままにします。
  7. Tenancy の値は「Default」のままにします。
    次のスクリーンショットは、この記事では名前 demoVPC と範囲 10.0.0.0/16 を入力していることを示しています。
  1. [Create] を選択します。

DynamoDB との間のデータベーストラフィックが VPC のプライバシー内にあることを確認する必要があります。DynamoDB はリージョンサービスです。つまり、VPC エンドポイントを作成することで、データベースとの間のトラフィックが VPC プライベートネットワーキングに確実に保持されるようにする必要があります。

DynamoDB 用の VPC エンドポイントを使用すると、VPC の Amazon EC2 インスタンスはプライベート IP アドレスを使用して、パブリックインターネットに曝されることなく DynamoDB にアクセスできます。EC2 インスタンスはパブリック IP アドレスを必要とせず、VPC にインターネットゲートウェイ、NAT デバイス、または仮想プライベートゲートウェイは必要ありません。エンドポイントポリシーを使用して、DynamoDB へのアクセスをコントロールします。VPC と AWS のサービスの間でのトラフィックは、Amazon ネットワークを離れません。詳細については、DynamoDB のための Amazon VPC エンドポイントを参照してください。

セキュリティグループとネットワーク ACL

ネットワーク ACL とセキュリティグループは、DynamoDB に直接は適用されません。ただし、VPC エンドポイントと VPC エンドポイントポリシーを使用してネットワーク分離を実現することができます。

ネットワーク ACL を使用して、セキュリティゾーンモデリングを実装します。詳細については、ネットワーク ACL を参照してください。セキュリティゾーンは、類似の信頼レベルのアセットを含む、明確に定義されたネットワーク境界を提供します。セキュリティゾーンはまた、明確さと推論の容易さをもたらし、特性に基づいてセキュリティゾーンに出入りするネットワークフローの制御方法を定義し、実施します。

以下の図は、セキュリティゾーンモデリングに対する 1 つのアプローチを表しています。

DynamoDB VPC エンドポイントを作成し、エンドポイントポリシーを適用する

セキュリティゾーンモデリングを実装するには、サブネットごとに DynamoDB VPC エンドポイントを作成します。データプレーンとコントロールプレーンのトラフィックを分離するには、各 VPC エンドポイントに適切なポリシーを適用します。

次の手順で、2 つの DynamoDB VPC エンドポイントを作成し、一方をアプリ層サブネットにアタッチし、もう一方をコントロールプレーンサブネットにアタッチします。

  1. VPC コンソールで、[Endpoints] を選択します。
    これらの手順を 2 回実行して、両方のサブネットに対して DynamoDB VPC エンドポイントを作成する必要があります。
  1. [Service category] で、[AWS services] を選択します。
  2. [Service name] では、[Gateway] インターフェイスタイプを選択します。
  1. [VPC] には、この VPC エンドポイントをアタッチする VPC を入力します。
  2. [Configure route tables] では、アプリ層とコントロールプレーンに関連付けられたサブネットを選択します。
    ルートテーブルを選択すると、VPC エンドポイントを介して DynamoDB への新しいプライベートアドレス指定可能なルートが作成されます。ルートテーブルに正しいサブネットが関連付けられていることを確認してください。
  1. [Policy] では、[Custom] を選択します。
  2. アプリ層またはコントロールプレーンのいずれかに関連するポリシーを入力します。
    アプリ層サブネットからのデータプレーントラフィックだけが許可されるようにするには、DynamoDB VPC エンドポイントに以下のポリシーを適用します。

    VPC Endpoint Policy
{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "DataPlane",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:PutItem",
                "dynamodb:Scan",
                "dynamodb:Query"
            ],
            "Resource": "arn:aws:dynamodb:[your_region]:[your_AWS_account_id]
:table/*/index/*"
        }
    ]
}

    コントロールプレーン操作がコントロールプレーンサブネットからだけ許可されるようにするには、DynamoDB VPC エンドポイントに以下のポリシーを適用します。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ControlPlane",
            "Effect": "Allow",
            "Action": [
                "dynamodb:CreateTable",
                "dynamodb:CreateBackup",
                "dynamodb:DeleteTable",
                "dynamodb:UpdateTable"
            ],
            "Resource": "arn:aws:dynamodb: [your_region]:[your_AWS_account_id]:table/*"
        }
    ]
}
  1. VPCコンソールに移動し、[Endpoints] を選択します。
  2. 各エンドポイントを選択し、[Edit Policy]をクリックして、それぞれの VPC エンドポイントポリシーをアタッチします。

Identity and Access Management

IAM は、AWS を基盤とするお客様が利用できる基本的なコントロールです。これは、AWS Well Architected フレームワークのセキュリティの柱の 5 つのベストプラクティスのうちの最初のものです。このフレームワークによって、信頼性があり、安全で、効率的で、費用対効果の高いシステムをクラウドで設計および運用するためのアーキテクチャ上のベストプラクティスを学ぶことができます。

IAM での作業を開始し、個々のユーザー、グループ、およびロールのアクセス要件を定義する前に、それらのアクセス要件をコントロールプレーン操作とデータプレーン操作で分けます。

コントロールプレーン操作

コントロールプレーン操作は、CreateTable、DeleteTable、UpdateTable、CreateBackup などの DynamoDB の管理機能です。これらはより高い特権の操作であるため、関連する特権をユーザーまたはロールに割り当てるときには十分に注意して厳密に行います。

次のサンプルコードは、DynamoDB での管理アクションの限定されたセットを許可します。このポリシーをユーザー、グループ、またはロールにアタッチすることができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LimitedAdmin",
            "Effect": "Allow",
            "Action": [
                "dynamodb:CreateTable",
                "dynamodb:CreateBackup",
                "dynamodb:DeleteTable",
                "dynamodb:UpdateTable"
            ],
            "Resource": "arn:aws:dynamodb: [your_region]:[your_AWS_account_id]:table/*"
        }
    ]
}

データプレーン操作

データプレーン操作とは通常、DynamoDB テーブルのデータを取得、書き込み、削除するアクションを指します。Amazon DynamoDB でデータプレーン操作を有効にするには、データベース認証とデータベースアクセスコントロールの 2 つの部分があります。

データベース認証とは、誰が DynamoDB テーブルへのアクセスを許可されているかを意味します。IAM で認証を設定します。人間のユーザーの場合、これは、IAM ロールを使用したフェデレーション ID (Microsoft Active Directory など) による認証、または IAM 認証情報の直接提供による認証です。アプリケーションによるアクセスの場合、IAM ロールをアプリケーションに直接アタッチして、認証済みアクセスを有効にします。

アクセスコントロールとは、ユーザーまたはアプリケーションが持つアクセスのレベルです。DynamoDB のアクセスコントロールも、IAM を使用して定義します。最小権限の原則でアプリケーションアクセス用の IAM ポリシーを作成することから始めます。読み取りおよび書き込みのユースケースを特定し、それぞれについて個別の IAM ポリシーを作成します。

次のサンプルコードは、特定の DynamoDB テーブルへのデータプレーンアクセスを許可します。それを、特定の IAM ユーザーまたは特定のアプリケーションに関連するロールにアタッチします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "App1Access",
            "Effect": "Allow",
            "Action": [
                "dynamodb:PutItem",
                "dynamodb:GetItem",
                "dynamodb:Scan",
                "dynamodb:Query",
                "dynamodb:UpdateItem"
            ],
            "Resource": "arn:aws:dynamodb:[your_region]:[your_AWS_account_id]:table/[App 1 table name]"
        }
    ]
}

DynamoDB 環境内でマイクロセグメンテーションを適用するには、より制限的なユーザーまたはロールのデータプレーン IAM ポリシーを使用します。たとえば、DynamoDB VPC エンドポイント IAM ポリシーは、すべての原則からすべてのテーブルへの Get、Put、Delete 操作を許可する場合がありますが、特定のユーザーまたはロールの IAM ポリシーは特定のテーブルへのアクセスだけを許可します。

次の図は、このマイクロセグメンテーションアプローチを示しています。

暗号化とトークン化

暗号化とトークン化は、データベースセキュリティの鍵です。保存時の暗号化を有効にすると、DynamoDB テーブルのアクセス許可に加えて、AWS KMS 暗号化キーのアクセス許可が明示的に付与された AWS アカウントの外部にある DynamoDB データベースと DynamoDB テーブルのバックアップに保存されたデータのみを読み取ることができます。

トークン化は、機密データを一意の識別子に置き換え、別のデータソースで元の機密データを見つけるために使用します。対照的に、暗号化では、機密データに暗号を適用して、許可された関係者だけが読み取ることができるようにデータをエンコードします。

サーバー側の暗号化

保存中のデータは、カスタムマスターキー (CMK) を使用して暗号化されます。AWS 管理型 CMK または AWS 所有型 CMK を選択できます。AWS CloudTrail ログでの使用を監査できるため、AWS 管理型 CMK を使用します。

新しい DynamoDB テーブルを作成するときに保存時の暗号化を有効にするには、次の手順を実行します。

  1. [Table settings] で、[Use default settings] を選択解除します。
  1. [Encryption at Rest] では、[KMS] を選択します。
  2. ドロップダウンメニューから、使用している KMS キーを選択します。
  3. [Create] を選択します。

クライアント側の暗号化

DynamoDB に送信する前にテーブルデータを暗号化するクライアント側の暗号化には、 DynamoDB 暗号化クライアントを使用します。これは、データの機密性とアプリケーションのセキュリティ要件に基づいて選択できます。詳細については、クライアント側およびサーバー側の暗号化を参照してください。

KMS を使用して、クライアント側の暗号化キーを管理します。KMS キー付与を使用して、アプリケーションによる暗号化されたデータへのアクセスを有効にします。クライアント側の暗号化を使用する利点の 1 つは、DynamoDB 暗号化クライアントに、主キー属性やテーブル名など、テーブル項目のすべてまたは一部の署名を計算するように指示できることです。この署名を使用すると、属性の追加や削除、属性値の交換など、項目全体に対する不正な変更を検出できます。

転送中の暗号化

転送中の暗号化により、アプリケーションと DynamoDB テーブル間でデータを移動するときにデータが暗号化されたままになります。DynamoDB に対して AWS マネジメントコンソール、CLI、AWS SDK のいずれを使用するかに関係なく、DynamoDB エンドポイントは HTTPS エンドポイント経由でアクセスできます。

トークン化

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

トークン化は、アプリケーションレベルの実装上の問題です。通常、トークンとそれに対応する機密データ値の間のマッピングを保持するために専用のデータストアを使用して実装します。トークンは機密データ値の代わりにアプリケーションデータベースに保存され、実行時にアプリケーションによって専用トークンデータストアから実際の値に置き換えられます。

次の図は、トークン化プロセスの例を示しています。

この図には、以下の手順があります。

  1. アプリケーションは、クレジットカード番号などの機密データをトークン化 API に提示します。
  2. トークン化 API は、アプリケーションユーザーの認証を要求します。
  3. 認証 API が、ユーザーを認証します。
  4. トークン化 API が、クレジットカード番号に対するトークンを生成し、トークンとクレジットカード番号とをトークン化データベースに保存してリンクさせます。
  5. トークン化 API が、トークンをアプリケーションに返します。
  6. アプリケーションは、クレジットカード番号の代わりにトークンをアプリケーションデータベースに保存します。

発見的コントロール

発見的コントロールもデータベースのセキュリティにとって重要です。

VPC フローログや CloudTrail ログをカスタムロジックで監視して異常を特定するなど、不正なトラフィックの発見を実装する方法はいくつかあります。VPC フローログの詳細については、VPC フローログを参照してください。CloudTrail ログの詳細については、CloudTrail ログファイルでの作業を参照してください。

DynamoDB は、CloudTrail と統合されています。CloudTrail が収集する情報を使用して、DynamoDB に対して行われたリクエスト、リクエストが行われた IP アドレス、リクエストを行ったユーザー、リクエストが行われた日時、および追加の詳細を確認できます。DynamoDB で実行できる操作には、コントロールプレーンとデータプレーンの 2 種類があります。

DynamoDB は、CreateTable、ListTables、UpdateTable API 呼び出しなどのコントロールプレーンイベントアクティビティを CloudTrail に自動的に公開します。詳細については、AWS CloudTrail を使用した DynamoDB オペレーションのログ記録を参照してください。

Amazon GuardDuty を有効にする

ネットワークトラフィックを自動的に監視し、機械学習を使用して異常な動作を検出して警告するには、Amazon GuardDuty を有効にします。以下の手順を完了してください。

  1. AWS マネジメントコンソールで、[Amazon GuardDuty] を選択します。
  2. [Get started] を選択します。
  1. [Enable GuardDuty] を選択します。

CloudWatch ルールの作成

GuardDuty の検出結果を監視して対処する CloudWatch ルールを作成します。Amazon SNS によって通知アラートを設定し、AWS Lambda による自動修復アクションを設定することもできます。以下の手順を完了してください。

  1. Amazon CloudWatch コンソールを開きます。
  2. [Events] で、[Rules] を選択します。
  3. [Create rule] を選択します。
  4. [Event Source] では、[Event Pattern] を選択します。
  5. ドロップダウンメニューから、[Build custom event pattern] を選択します。
  6. 以下のコードを入力します。 
    {
	"source": ["aws.guardduty"],
	"detail": {
		"type": ["UnauthorizedAccess: IAMUser / MaliciousIPCaller.Custom"]
	}
}
  7. [Targets] では、[Add target] を選択します。
  8. ドロップダウンメニューから、[SNS topic] を選択します。
  9. [For Topic] では、使用している SNS トピックの名前を選択します。
  10. [Configure details] を選択して、ルールの名前と説明を入力し、プロセスを完了します。

次のスクリーンショットは、これらの完了した手順を示しています。

設定のドリフト

設定のドリフトでは、初期デプロイ後のシステムを変更することで、システムの現在のセキュリティ設定が望ましい強化状態から逸脱する可能性があります。

AWS CloudFormation ドリフト検出を使用すると、設定のドリフトをオンデマンドで識別できます。ベースライン設定に対してデータベースの設定を継続的に監視し、設定がベースラインから逸脱したときにアラートを送信するには、AWS Config を使用します。

これを設定するには、以下の手順を完了してください。

  1. AWS Config コンソールを開きます。
  2. [Events] で、[Rules] を選択します。
    初めて AWS Config を有効にする場合は、初期セットアッププロセスが実行されることがあります。
  3. [Add rule] を選択します。
  4. 検索ボックスに、「dynamodb」と入力します。
  5. 有効にしたい DynamoDB 設定チェックを選択します。
    DynamoDB の事前定義ルールを検索して選択するか、新しいカスタムルールを作成します。

きめ細かい監査

コントロールプレーン操作またはデータプレーン操作を使用して、データベースセキュリティを強化するために、追加のきめ細かい監査を実行できます。詳細については、Amazon DynamoDB での Identity and Access Management を参照してください。

コントロールプレーン操作

DynamoDB コントロールプレーン操作とは、CreateTable、DescribeTable、ListTables などの DynamoDB テーブルでの管理機能を意味します。すべての Amazon DynamoDBコントロールプレーン操作は CloudTrail によって記録され、DynamoDB API に文書化されています。

新しい証跡を作成すると、すべての CloudTrail ログを監査目的で Amazon S3 に保存することができます。詳細については、AWS CloudTrail を使用した DynamoDB オペレーションのログ記録を参照してください。

新しい証跡を作成するには、以下の手順を完了してください。

  1. CloudTrail コンソールを開きます。
  2. [Trails] を選択します。
  3. [Create trail] を選択します。

次のスクリーンショットは、CloudTrail によって記録されたすべての DynamoDB API 呼び出しに一致し、ユーザー定義の通知またはアクションをトリガーできる Amazon CloudWatch ルールを作成するには、以下の手順を完了してください。

  1. CloudWatch コンソールを開きます。
  2. [Events] で、[Rules] を選択します。
  3. [Create rule] を選択します。
  4. [Event Source] では、[Event Pattern] を選択します。
  5. ドロップダウンメニューから、[Build custom event pattern] を選択します。
  6. [Service Name] では、[DynamoDB] を選択します。
  7. [Event Type] については、[AWS API Call via CloudTrail] を選択します。
  8. [Any operation] を選択します。
  9. [Targets] では、[Add target] を選択します。
  10. ドロップダウンメニューから、[SNS topic] を選択します。
  11. [For Topic] では、使用している SNS トピックの名前を選択します。

次のスクリーンショットは、これらの完了した手順を示しています。

データプレーン操作

CloudTrail は、GetItem や PutItem などの DynamoDB データプレーン操作のロギングをサポートしていません。DynamoDB ストリームは、環境で発生するアイテムレベルの変更イベント (作成、更新、削除) のソースとして使用できます。監査の必要性がある場合は、アプリケーション層内でデータプレーンの読み取り操作を記録する必要があります。

DynamoDB は AWS Lambda と統合され、DynamoDB ストリームのイベントに自動的に応答するトリガーを作成します。トリガーを使用すると、DynamoDB テーブルのデータ変更に反応するアプリケーションを構築できます。テーブルで DynamoDB ストリームを有効にすると、ストリームの Amazon リソースネーム (ARN) を Lambda 関数に関連付けることができます。テーブル内のアイテムを変更するとすぐに、テーブルのストリームに新しいレコードが表示されます。AWS Lambda は、ストリームをポーリングし、新しいストリームレコードを検出すると Lambda 関数を同期的に呼び出します。Lambda 関数は、通知の送信やワークフローの開始など、指定したアクションを実行できます。詳細については、Amazon DynamoDB ストリームでの AWS Lambda 関数の使用を参照してください。

ベストプラクティスは、最小権限を実装することです。たとえば、DynamoDB テーブル内のアイテムの特定の属性へのアクセスを制限するには、きめの細かいアクセスコントロールを使用します。きめ細かいアクセスコントロール使用すると、アイテムを表示、編集、削除できるユーザーを制限できます。詳細については、きめ細かいアクセスコントロールのための IAM ポリシー条件の使用を参照してください。

ユーザー名と属性名を指定してアクセスをコントロールする IAM ポリシー条件を使用して、属性ベースのアクセスコントロール (ABAC) を適用します。詳細については、YouTube で AWS re:Inforce 2019: Scale Permissions Management in AWS w/ Attribute-Based Access Control をご覧ください。

ユーザー名を指定するには、置換変数 ${www.amazon.com:user_id} を使用します。これは、ユーザー名を「dynamodb:LeadingKeys」条件キーの組み合わせで DynamoDB を呼び出すユーザーと置き換えます。これにより、アイテムへのアクセスをその特定のユーザーに制限できます。

たとえば、マネージャー MNG001 および MNG002 に報告する従業員 EMP001、EMP002、EMP003 がいるとします。次のテーブルには、緊急連絡先の詳細が含まれています。

ManagerID (パーティションキー) Reporting_Employee (ソートキー) Emergency_Contact
MNG001 EMP001 1234
MNG001 EMP002 456
MNG002 EMP003 987

上記のテーブルのアイテムを作成した後、マネージャーを表す各 IAM ユーザーとロールに以下のポリシーを追加します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccessToOnlyItemsMatchingUserID",
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:BatchGetItem",
                "dynamodb:Query",
                "dynamodb:PutItem",
                "dynamodb:UpdateItem",
                "dynamodb:DeleteItem",
                "dynamodb:BatchWriteItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-west-2:[YOUR ACCOUNT ID]:table/[TABLE NAME]"
            ],
            "Condition": {
                "ForAllValues:StringEquals": {
                    "dynamodb:LeadingKeys": [
                        "${www.amazon.com:user_id}"
                    ]
                }
            }
        }
    ]
}

上記のポリシーをアタッチすると、マネージャーは自分の詳細と、自分に報告するユーザーの緊急連絡先の詳細だけを表示できます。

アイテムレベルおよび属性レベルでのきめ細かいアクセスコントロールの適用の詳細については、きめ細かいアクセスコントロールのための IAM ポリシー条件の使用を参照してください。

スイムレーンの隔離

さまざまなビジネスドメインのデータベースやアプリケーションの間でサブネットレベルの厳密な分離を実現するために、スイムレーンの隔離を実装します。DynamoDBのスイムレーン分離を実装するには、前述のように VPC エンドポイントを使用します。スイムレーンの隔離の詳細については、AWS データストア内の機密データを保護するためのベストプラクティスを参照してください。

まとめ

この記事では、このブログシリーズの最初の記事で説明した一般的なデータセキュリティパターンを DynamoDB データベースに適用する方法について説明しました。これを実行すると、機密データに関して強力なセキュリティ体制を構築するのに役立ちます。

また、この記事では、階層型アプローチを使用して徹底的な防御を構築し、DynamoDB データベースを保護する方法も示しました。このアプローチでは、VPC 内のネットワーク ACL とサブネットを使用するネットワークセキュリティゾーンを使用します。

さらに、AWS ネットワーキング、IAM、およびデータベースサービス内で AWS の予防的なセキュリティコントロールの組み合わせを有効にする方法についても学びました。この記事では、Amazon GuardDuty、AWS Config、CloudTrail を使用して発見的コントロールを設定し、データの徹底的な防御を可能にする方法についても取り上げました。DynamoDB 入門ガイドで DynamoDB の詳細をご確認ください。いつものように、AWS はフィードバックをお待ちしていますので、コメントや質問を以下に残してください。

 

著者について

 

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

 

 

 

Masudur Rahaman Sayem はアマゾン ウェブ サービスのソリューションアーキテクトです。 AWS を使用している場合にソリューションの価値を向上させるサポートができるように、AWS の顧客と協力してデータベースプロジェクト上の指導や技術支援を行っています。