[前回] AWS公式資料で挑むSCS認定(47)-こんな時どうする(全分野その24)

はじめに

今回も引き続き、「こんな時どうする」集の作成です。

分野1: インシデント対応

OSI参照モデルのネットワーク層(レイヤー3)とトランスポート層(レイヤー4)へのDDoS攻撃が報告された
- AWS Shield Standardを使用し(追加料金なし)、ウェブサイトやアプリケーションを標的としたネットワーク層とトランスポート層へのDDoS攻撃を防御できる
- 分散サービス妨害(DDoS)攻撃は、複数デバイスから大量のパケットを攻撃対象のWebサーバーに送りつけ、正常なサービス提供を妨げる攻撃
- AWS Shield StandardをAmazon CloudFrontおよびAmazon Route 53と合わせて使用することで、総合的にDDoS攻撃を緩和できる

分野2: ログとモニタリング(監視)

EC2 Linuxインスタンスでファイルシステムに加えられたセキュリティ関連変更を監視したい
- ホストベース侵入検知システム(IDS)のLinux Auditシステムを使用し、重要なファイルへのアクセス追跡し、ファイル破損やその他意図しない変更が発生した場合に監査証跡を作成できる
  - Amazon Elastic File System(Amazon EFS)またはその他のファイルシステムタイプのファイルへの変更を追跡できる
  - ファイルシステムに対するすべての変更を追跡するには、ファイルシステムをマウントするすべてのクライアントでLinux Auditシステムを有効にする必要あり
- Linux Auditシステムをインストール
  - SSHを使って、rootユーザーでEC2インスタンスに接続し、以下コマンドを実行
    - # sudo yum install audit
- ファイルシステム上のアクティビティを監視するルールを作成
  - auditctlコマンドを使用し、ルールをテストしてから追加または削除
  - マウントされているすべてのファイルシステムのアクティビティ監視例：
    - $ auditctl -w /home/ec2-user/efs -k efs_changes
  - ルールを保持するには、/etc/audit/audit.rulesファイルでルールを設定
  - ※ Auditシステム設定で、ログ記録対象種類が多いと、ローカルシステムのパフォーマンスに影響する
    - すべての操作を記録せず、削除関連のアクションのみログ記録するルール例
      - auditctl -a always,exit -F arch=b64 -F dir=/home/ec2-user/efs -S unlink -S unlinkat -S rename -S renameat -S rmdir -k efs_changes
- 記録ログを出力し、Amazon CloudWatch Logsに送信
  - ログを記録するように、Auditシステムを設定
  - ausearch -k efs_changesコマンドを使用し、監査ログを表示
  - aureportコマンドを使用し、Auditログファイルに記録されたイベントに関するサマリーおよび列レポートを生成
    - $ ausearch -k efs_changes | aureport -f -i

分野3: インフラストラクチャのセキュリティ

VPCプライベートサブネット内のEC2インスタンスからインターネットに接続したい
- NATデバイスを使用し、インターネットまたは他のネットワークに接続
  - プライベートサブネット内のリソースから、インターネット、他のVPC、オンプレミスのネットワークへの接続を許可できる
  - これらのインスタンスはVPC外のサービスと通信できるが、未承諾の接続リクエストの受信はできない
- NATデバイスは、インスタンスの送信元IPv4アドレスをNATデバイスのアドレスに置き換える
  - 外部からインスタンスへ応答トラフィックを送信するとき、NATデバイスはアドレスを元の送信元IPv4アドレスに変換
- NATゲートウェイを使用すると、可用性と帯域幅が向上し、管理にかかる負担が軽減される
  - NATゲートウェイは、AWSが提供するマネージドNATデバイス
  - NATインスタンスと呼ばれるEC2インスタンス独自のNATデバイスを作成することも可能
- NATデバイスはIPv6トラフィックに対応していない
  - Egress-Onlyインターネットゲートウェイを使用し、アウトバウンドIPv6トラフィックを有効にできる

分野4: アイデンティティ(ID)及びアクセス管理

S3を含む複数サービスへのアクセスが許可されているIAMグループに所属する、特定IAMユーザーAにS3以外のサービスを許可しない
- IAMエンティティのアクセス許可の境界を使用
  - アクセス許可の境界とは、管理ポリシーを使用し、IDベースポリシーがIAMエンティティに付与できるアクセス許可の上限を設定する機能
- アクセス許可の境界により、IAMエンティティは、IDベースポリシーとアクセス許可の境界の両方で許可されているアクションのみ実行できる
- IAMエンティティ(ユーザーまたはロール)の境界は、AWS管理ポリシーまたはカスタマー管理ポリシーを使用し設定
  - ユーザーAのアクセス許可上限をAmazon S3管理のみに制限する設定例
    - "Effect": "Allow"
    - "Action": ["s3:*"]
    - "Resource": "*"
- アクセス許可の境界ポリシーは、ユーザーのアクセス許可を制限するだけで、アクセス許可は提供しない
  - 別のアクセス許可ポリシーでユーザーAにS3サービスへのアクセス許可を付与する必要がある
    - "Effect": "Allow"
    - "Action": ["s3:*"]
    - "Resource": "*"
  - ※ 上記アクセス許可ポリシーでS3以外のサービスを許可しても、アクセス許可の境界ポリシーの制限により操作はできない
    - 例えば、IAMユーザーの作成を許可しても機能しない
    - "Action": ["iam:CreateUser"]

分野5: データ保護

AWS KMSのカスタマー管理キー(CMK)を三日後に削除したい
- キーマテリアルの有効期限を設定し、手動で削除可能、かつ再利用できる
  - KMSキーは、暗号化キーの論理表現で、キー識別子とその他メタデータに加え、データの暗号化と復号に使用されるキーマテリアルが含まれている
  - KMSキーを作成すると、デフォルトでAWS KMSがキーマテリアルを生成する
  - ただし、キーマテリアルを使用せずKMSキーを作成し、独自のキーマテリアルをKMSキーにインポートできる、「キーの持ち込み」(BYOK) とも呼ばれる
- AWS KMSでは、暗号化テキストが、インポートされたキーマテリアルを持つKMSキーで暗号化された場合でも、外部からAWS KMS暗号化テキストの復号リクエストはサポートしない(復号APIは存在しない)
  - AWS KMSはこのタスクに必要な暗号化テキスト形式を公開しない
- インポートされたキーマテリアルを使用する場合、以下の理由でユーザーがキーマテリアルに対し責任を持つ(AWS KMSがそのコピーを使用中であっても)
  - 要件を満たすエントロピーのソースを使用してキーマテリアルを生成したことを証明するため
  - AWSサービスのインフラストラクチャでキーマテリアルを使用するため
  - AWS KMSを使用し、キーマテリアルのライフサイクルを管理するため
  - AWSのキーマテリアルの有効期限を設定し、手動で削除しながらも、将来的に再利用できるようにするため
    - これに対して、キー削除のスケジュール機能は、7日から30日間の待機時間が必要で、削除されたKMSキーは復元できない
  - キーマテリアルのオリジナルコピーを所有し、それをAWSの外に保存し、キーマテリアルのライフサイクル期間に耐久性を高め障害復旧を行うため
- インポートされたキーマテリアルのサポート
  - AWS KMSキーストアの対称KMSキーでのみサポート(マルチリージョン対称KMSキーを含む)
  - 非対称KMSキーまたはカスタムキーストアのKMSキーではサポートされない
- インポートされたキーマテリアルを使用し、KMSキーの使用と管理を監視可能
  - AWS KMS下記関連操作は、AWS CloudTrailログに記録される
    - KMSキー作成
    - 公開キーとインポートトークンをダウンロードし、キーマテリアルをインポート
    - インポートされたキーマテリアルを手動で削除
    - AWS KMSが期限切れのキーマテリアルを削除

おわりに

「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。

[次回] AWS公式資料で挑むSCS認定(49)-こんな時どうする(全分野その26)