[前回] AWS公式資料で挑むSCS認定(50)-こんな時どうする(全分野その27)
はじめに
今回も引き続き、「こんな時どうする」集の作成です。
分野1: インシデント対応
- Amazon CloudFrontが配信しているコンテンツへ、許可されていない国からの不正アクセス発生
- 地域制限(地理的ブロック)を使用し、CloudFrontディストリビューション経由で配信しているコンテンツに対し、特定地域のユーザーによるアクセスを回避できる
- 方法1: CloudFrontの地域制限機能を使用し、国レベルでアクセス制限
- ディストリビューションに関連するすべてのファイルへのアクセスを制限
- 方法2: サードパーティーの位置情報サービスを使用し、国レベルより詳細なレベルでアクセス制限
- ディストリビューションに関連するファイルのサブセットへのアクセスを制限
- 方法1: CloudFrontの地域制限機能を使用し、国レベルでアクセス制限
- CloudFrontの地域制限機能
- 承認された国のリストに含まれている国のユーザーのみ、コンテンツへのアクセスを許可
- ブロックリストにある国のユーザーは、コンテンツへのアクセスを禁止
- CloudFrontは、サードパーティーのデータベースを使用し、ユーザーの場所を判別
- IPアドレスと国とのマッピングの正確さは、リージョンによって異なるが、全体的に99.8%正確
- CloudFrontがユーザーの場所を特定できない場合、ユーザーがリクエストしたコンテンツは提供される
- 地域制限の仕組み
- CloudFrontディストリビューションを更新し、コンテンツ配信権限を持つ国を許可リストに追加
- 許可されていない国からコンテンツへリクエストがあった場合、DNSはそのリクエストを当該国のCloudFrontエッジロケーションにルーティング
- エッジロケーションがユーザーのディストリビューションを検索
- ユーザーがコンテンツダウンロードを許可されていないと判断された場合、HTTPステータスコード403(Forbidden)をユーザーに返す
- オプション
- ユーザーにカスタムエラーメッセージを返すように、CloudFrontを設定できる
- リクエストされたファイルに関するエラーレスポンスをキャッシュ可能で、保持時間の長さを指定できる(デフォルトは10秒)
- 地域制限はディストリビューション全体に適用される
- コンテンツのある部分に特定制限を適用したい場合、別のCloudFrontディストリビューションを作成するか、サードパーティーの位置情報サービスを使用する必要あり
- CloudFrontで拒否されたリクエストを特定したい
- CloudFrontの標準ログ(アクセスログ)を有効にし、
sc-status(HTTPステータスコード)の値が403であるログエントリを検索 - 標準ログだけでは、ユーザーの場所に基づき拒否されたか否かの理由までは判別できない
- Digital ElementやMaxMindなどサードパーティーの位置情報サービスを利用している場合、アクセスログの
c-ip(クライアント IP)列にあるIPアドレスに基づいてリクエストの場所を識別できる
- Digital ElementやMaxMindなどサードパーティーの位置情報サービスを利用している場合、アクセスログの
- CloudFrontの標準ログ(アクセスログ)を有効にし、
- 地域制限(地理的ブロック)を使用し、CloudFrontディストリビューション経由で配信しているコンテンツに対し、特定地域のユーザーによるアクセスを回避できる
分野2: ログとモニタリング(監視)
- GuardDutyを一時的に無効にしたい
- GuardDutyコンソールを使用し、GuardDutyを停止または無効化できる
- サービスの停止中は、GuardDuty対し課金されない
- GuardDutyを無効または停止する前に、すべてのリージョンのすべてのディテクターからすべてのオプションのデータソースを無効にする必要あり
- GuardDutyを無効または停止するには、すべてのメンバーアカウントの関連付けを解除または削除する必要あり
- GuardDutyを停止すると、AWS環境のセキュリティはモニタリングされなくなり、新しい検出結果は生成されない
- ただし、既存の検出結果は変更されず、GuardDutyの停止によって影響を受けない、再度有効にできる
- GuardDutyを無効にすると、既存の検出結果とGuardDutyの設定は失われ、復旧できなくなる
- 既存の検出結果を保存する場合は、GuardDutyを無効にする前にエクスポートする必要あり
- GuardDutyコンソールを使用し、GuardDutyを停止または無効化できる
分野3: インフラストラクチャのセキュリティ
- リモートのネットワークからVPCに安全に接続したい
- AWS VPN(Virtual Private Network)を使用し、VPCをリモートネットワークに接続可能
- 下記VPN接続オプションを使用すると、VPCをリモートネットワークおよびユーザーに接続できる
- AWS Site-to-Site VPN
- VPCとリモートネットワーク間で、IPsecおよびVPN接続を作成できる
- Site-to-Site VPN接続のAWS側は、仮想プライベートゲートウェイまたはトランジットゲートウェイ
- 自動フェイルオーバーのため、2つのVPNエンドポイント(トンネル)が提供される
- Site-to-Site VPN接続のリモート側は、カスタマーゲートウェイデバイス
- AWS Client VPN
- AWSリソースまたはオンプレミスネットワークに安全にアクセスできる、クライアントベースのマネージドVPNサービス
- ユーザーが接続時に安全なTLS VPNセッションを確立できるエンドポイントあり
- クライアントはOpenVPNベースのVPNクライアントを使用し、どこからでもAWSまたはオンプレミスのリソースにアクセスできる
- AWS VPN CloudHub
- リモートネットワークが複数ある(複数支社など)場合、仮想プライベートゲートウェイを通じて複数のAWS Site-to-Site VPN接続を作成することで、ネットワーク間で通信できる
- サードパーティー製ソフトウェア
- VPNアプライアンス
- サードパーティー製ソフトウェアのVPNアプライアンスを実行するEC2インスタンスを使用し、リモートネットワークへのVPN接続を作成できる
- AWSは、サードパーティー製ソフトウェアVPNアプライアンスを提供および維持しない
- ただし、AWS Marketplaceでパートナーやオープンソースコミュニティが提供する様々な製品を選択できる
- VPNアプライアンス
- AWS Direct Connect
- リモートネットワークからVPCへの専用プライベート接続を作成できる
- この接続をAWS Site-to-Site VPN接続と組み合わせると、IPsecで暗号化された接続を作成できる
- AWS Site-to-Site VPN
分野4: アイデンティティ(ID)及びアクセス管理
- IDベースポリシーとリソースベースポリシー、両方適用されている場合、IAMユーザーのアクセス許可を判断したい
- IDベースポリシーが、
userAにアタッチされている- バケットの名前に
protectが含まれているS3バケットへのアクセスをuserAに拒否
- バケットの名前に
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyS3protect", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*protect*" } ] }- リソースベースポリシー(バケットポリシー)が、
bucketBにアタッチされている- ユーザー
userAのみバケットbucketBへアクセス可
- ユーザー
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/userA" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucketB/*", "arn:aws:s3:::bucketB" ] } ] }- 最終的に
userAのアクセス許可はいかが- 明示的拒否により、バケット
my-protect-bucketへのデータ保存は拒否される - 明示的許可により、バケット
bucketBへのデータ保存は許可される(二つのポリシーで片方だけ許可されたらOK) - 暗黙的拒否により、バケット
bucketCへのデータ保存は拒否される(明示的に許可されていないため)
- 明示的拒否により、バケット
- IDベースポリシーが、
分野5: データ保護
- クライアントからDynamoDBまで、エンドツーエンドのデータ保護を実現したい
- DynamoDBサーバー側の保管時の暗号化
- DynamoDBデフォルトの暗号化機能により、ディスクに書き込まれる際、すべてのテーブルが透過的に暗号化される
- 保管時の暗号化を有効または無効にするオプションはない
- テーブルへのアクセス時に復号される
- サーバー側の暗号化により、データはHTTPS接続で転送時に暗号化される
- DynamoDBエンドポイントで復号された後、DynamoDBに保管される前に再度暗号化される
- DynamoDB暗号化クライアントとサーバー側暗号化を両方使用できる
- 暗号化/署名された項目をDynamoDBに送信しても、DynamoDBは項目が保護されているとして認識しない
- DynamoDBデフォルトの暗号化機能により、ディスクに書き込まれる際、すべてのテーブルが透過的に暗号化される
- DynamoDB暗号化クライアント
- DynamoDB暗号化クライアントを用いたクライアント側暗号化により、テーブルデータをDynamoDBに送信する前に暗号化
- クライアント側の暗号化により、エンドツーエンドソースからDynamoDBストレージまで、転送時および保管時のデータを保護できる
- DynamoDB暗号化クライアントは、暗号化されていないDynamoDBテーブルデータの暗号化はサポートしない
- 新しい未入力データベースのみ実装可能
- DynamoDBにデータ送信する前に、DynamoDBアプリケーションに暗号化機能を追加する必要あり
- プライマリキー属性やテーブル名などのテーブル項目に署名可能
- すべてまたは一部テーブル項目の署名により、属性の追加や削除、属性値のスワップなど、項目全体への不正変更を検出できる
- 暗号化キーの生成および保護方法を選択し、キーを保護できる
- ユーザーがキーを作成して管理する
- または、AWS KMSまたはAWS CloudHSMなど暗号化サービスを使用
- データの保護方法の決定
- 暗号化マテリアルプロバイダー(CMP)を選択する
- CMPが、一意キーが生成されるタイミングや、使用する暗号化アルゴリズムおよび署名アルゴリズムなど、使用する暗号化の方法を判断
- または、独自のものを記述
- 暗号化マテリアルプロバイダー(CMP)を選択する
- DynamoDB暗号化クライアントを用いたクライアント側暗号化により、テーブルデータをDynamoDBに送信する前に暗号化
- AWS Encryption SDK
- クライアント側暗号化ライブラリで、汎用データの暗号化および復号に使用
- 任意タイプのデータを保護できるが、データベースレコードなど構造化データは操作できない
- DynamoDB暗号化クライアントとは異なり、項目レベルの整合性チェックはできない
- 属性に基づきプライマリキーの暗号化を回避するロジックはない
- AWS Encryption SDKとDynamoDB暗号化クライアントとの互換性はない
- 1つのライブラリで暗号化し、もう1つのライブラリで復号はできない
- DynamoDBの保管データを暗号化する場合、DynamoDB暗号化クライアントがお勧め
- DynamoDBサーバー側の保管時の暗号化
おわりに
「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。