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

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

はじめに

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

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

• OSI参照モデルのネットワーク層(L3)/トランスポート層(L4)/アプリケーション層(L7)へのDDoS攻撃が報告された
  • AWS Shield Advancedを使用し(追加料金あり)、ウェブサイトやアプリケーションを標的としたDDoS攻撃を防御できる
    • AWS Shield Advancedにサブスクライブし、保護対象のリソースを追加することで、リソース上で実行されるウェブアプリケーションをDDoS攻撃から保護
    • ※ 指定されたリソースのみ保護し、AWS Firewall ManagerShieldアドバンスドリソースは自動的に保護されない
  • Shield Advanced保護を追加可能なリソースタイプ
    • Amazon CloudFrontディストリビューション
    • Amazon Route 53ホストゾーン
    • AWS Global Acceleratorアクセラレーター
    • Application Load Balancer
    • Elastic Load Balancing ad Balancer
    • Amazon EC2 Elastic IP
  • NLB(ネットワークロードバランサー)の保護
    • Shield Advanced保護をNLBに直接アタッチはできないが、ELBにElastic IPアドレス(EIP)を関連付けてから、EIPをShield Advanced保護リソースとして追加可能
      • スケーリングツールAWS Elastic Beanstalkで、EIPをNLBに自動アタッチできない場合、EIPをNLBに関連付けてから、Shield Advanced保護をEIPに手動追加する必要あり
  • Shield Advancedを使用しEIPを保護することで、NACL(ネットワークACL)が大容量のDDoSイベントに対処できる
    • 通常、NACLはVPCとEC2インスタンスが処理できるネットワークトラフィック容量の攻撃しか緩和できず、それを超えるとインスタンスへのトラフィックがブロックされる可能性あり
    • Shield Advancedにより数テラバイトのトラフィックを処理できるようになり、NACLが通常処理可能なネットワーク容量を超えてもリソースを保護できる
  • AWS Shield Advancedユーザーは、DDoS攻撃時の支援を24時間365日行うShield Response Team(SRT)の助けを借りて、高度なリアルタイムメトリクスとレポートへの排他的アクセスを利用しDDoS攻撃をさまざまな視点から特定できる
    • SRTサービスを使用するには、ビジネスまたはエンタープライズのサポートプランが必要
  • AWS Shield Advancedは、DDoS攻撃によって生じるAWSリソース使用料急増に対するコスト保護も提供

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

• AWS CloudTrailの証跡ログをモニタリングしたい
  • Amazon CloudWatch LogsでCloudTrailを使用するように設定し、証跡ログをモニタリングすることで、特定アクティビティ発生時に通知を受けることができる
  • CloudWatch Logsにログイベントを送信するように証跡を設定
  • ログイベントの中に一致する語句や値があるかどうかを評価するためのCloudWatch Logsメトリクスフィルタを定義
  • 指定されたしきい値と期間に基づいてトリガーされるCloudWatchアラームを作成し、通知を送信
    • アラームへの対応アクションが自動的に実行されるように、CloudWatchを設定できる

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

• IPv6経由でVPCからインターネットへ送信を行いたい
  • Egress-Onlyインターネットゲートウェイを使用し、アウトバウンドIPv6トラフィックを有効にする
    • 水平にスケールされ、冗長で高度な可用性を持つVPCコンポーネント
    • IPv6トラフィックのみ使用可能で、IPv4経由の送信専用のインターネット通信を可能にするには、代わりにNATゲートウェイを使用
    • IPv6アドレスはグローバルに一意であるため、デフォルトではパブリックアドレスになっている
  • VPCでEgress-Onlyインターネットゲートウェイを作成
    • すべてのIPv6トラフィック(::/0)または特定IPv6アドレス範囲をポイントするルートテーブルに、Egress-Onlyインターネットゲートウェイへのルートを追加
    • ルートテーブルに関連付けられるサブネットのIPv6トラフィックは、Egress-Onlyインターネットゲートウェイにルーティングされる
  • Egress-Onlyインターネットゲートウェイはステートフル
    • サブネットのインスタンスからインターネットや他のAWSサービスに転送し、その応答をインスタンスへ戻す
  • Egress-Onlyインターネットゲートウェイの特性
    • セキュリティグループと関連付けることはできない
      • セキュリティグループは、プライベートサブネットのインスタンスに対し使用し、それらのインスタンスに出入りするトラフィックを管理
    • ネットワークACLを使用し、Egress-Onlyインターネットゲートウェイとサブネット間でルーティングされるトラフィックを制御できる
  • Egress-Onlyインターネットゲートウェイの構成例
    • VPCにIPv4とIPv6両方のCIDRブロックあり
    • サブネットにIPv4とIPv6両方のCIDRブロックあり
    • VPCに、Egress-Onlyインターネットゲートウェイが存在
      
      ※ 引用元: https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/egress-only-internet-gateway.html
  • サブネットに関連付けられているルートテーブルの例
    • インターネットにバインドされたすべてのIPv6トラフィック(::/0)をEgress-Onlyインターネットゲートウェイに送信するルートが存在

    送信先	                ターゲット
    10.0.0.0/16             ローカル
    2001:db8:1234:1a00:/64  ローカル
    ::/0                    eigw-id
    

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

• IAMユーザーに複数アクセス許可タイプが適用された場合、最終的に有効となるアクセス許可を判断したい
  • IAMユーザーやロールなどエンティティに与えられるアクセス許可は、適用されるすべてのポリシーを評価する必要あり
  • いずれかのポリシータイプによって、オペレーションへのアクセスが明示的に拒否された場合、そのリクエストは拒否される
  • エンティティのアクセス許可は、アカウント内の下記ポリシーの影響を受ける
    • IDベースのポリシー
      • IAMユーザー/グループ/ロールにアクセス許可を付与する、インラインポリシーまたは管理ポリシー
    • リソースベースのポリシー
      • 指定されたプリンシパルが、ポリシーがアタッチされているリソースにアクセスする方法を制御
      • 同じアカウント内で、IAMユーザーARN(フェデレーティッドユーザーセッションではない)へアクセス許可を与えているリソースベースのポリシーは、IDベースのポリシーまたはアクセス許可の境界の暗黙的な拒否によって制限されない
      • IAMロールARNにアクセス許可を与えるリソースベースのポリシーは、アクセス許可の境界またはセッションポリシーの暗黙的な拒否によって制限される
      • 同じアカウント内で、IAMロールセッションARNにアクセス許可を与えるリソースベースのポリシーは、引き受けたロールセッションに、直接アクセス許可を与える
        • セッションに直接付与されるアクセス許可は、IDベースのポリシー、アクセス許可の境界、セッションポリシーの暗黙的な拒否によって制限されない
        • ロールを引き受けてリクエストを行う場合、リクエストを行うプリンシパルはIAMロールセッションARNであり、ロール自体のARNではない
      • IAMフェデレーティッドユーザーセッションは、GetFederationTokenを呼び出して作成されたセッション
        • フェデレーティッドユーザーがリクエストを行う場合、リクエストを行うプリンシパルはフェデレーティッドユーザーARNで、フェデレーションしたIAMユーザーのARNではない
        • 同じアカウント内で、フェデレーティッドユーザーARNにアクセス許可を与えるリソースベースのポリシーは、セッションに直接アクセス許可を与える
        • セッションに直接付与されるアクセス許可は、IDベースのポリシー、アクセス許可の境界、セッションポリシーの暗黙的な拒否によって制限されない
        • ただし、リソースベースのポリシーがフェデレーションしたIAMユーザーのARNにアクセス許可を与える場合、セッション中にフェデレーティッドユーザーによって行われたリクエストは、アクセス許可の境界またはセッションポリシーの暗黙的な拒否によって制限される
    • アクセス許可の境界
      • IAMエンティティ(ユーザーまたはロール)に許可されるアクセス許可の上限が設定される
    • Organizations SCP
      • AWSアカウント全体に適用され、アカウント内のプリンシパルによって行われるすべてのリクエストのアクセス許可が制限される
      • IAMエンティティ(ユーザーまたはロール)からのリクエストは、SCP、アクセス許可の境界、IDベースのポリシー、3つすべてのポリシータイプで許可されている場合にのみ許可される
      • 有効なアクセス許可は、3つすべてのポリシータイプの共通部分で、いずれかを明示的に拒否した場合、その許可は無効となる
      • 自分のアカウントがAWS Organizationsの組織メンバーか否かの判断方法
        • AWS CLIコマンドまたはAWS APIオペレーションを使用する場合、Organizationsエンティティに対する organizations:DescribeOrganizationアクションのアクセス許可が必要
        • Organizationsコンソールでオペレーションを実行する場合、追加のアクセス許可が必要
    • セッションポリシー
      • IAMロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシー
      • セッションのアクセス許可は、セッションの作成に使用するIAMエンティティ(ユーザーまたはロール)と、セッションポリシーから派生する
      • エンティティのIDベースポリシーのアクセス許可は、セッションポリシーとアクセス許可の境界で制限される
        • 有効なアクセス許可は、3つすべてのポリシータイプの共通部分
        • ポリシーのいずれかを明示的に拒否した場合、その許可は無効になる

分野5: データ保護

• AWS Lambdaで使用する環境変数を保護したい
  • 環境変数は、関数バージョン固有の設定に保存される文字列のペアで、コードを更新せず関数の動作を調整できる
  • ※ 注意: データベースのセキュリティ強化のため、環境変数の代わりにAWS Secrets Managerを使用し、データベースの認証情報を保存
  • 関数コードで環境変数の評価を実行
    • 関数呼び出し前には定義した値はリテラル文字列とみなされ、評価されず展開されない
  • 環境変数は、関数の未公開バージョンで定義し、バージョン公開時、他のバージョン固有の設定とともにロックされる
  • 関数の環境変数を作成するには、キーと値を定義
    • 関数は、キーの名前を使用し、環境変数の値を取得
  • 関数の暗号化キーを設定するには、--kms-key-arnオプションを設定
  • 環境変数の保護
    • サーバー側の暗号化を使用し、保管中データを保護
      • Lambdaは、常にAWS KMS key(KMSキー)でサーバー側暗号化を提供
        • デフォルトでは、AWS管理キーを使用、追加の設定は必要なし
        • 必要に応じて、AWS KMSカスタマー管理キーを使用
          • KMSキーのローテーション制御やKMSキー管理に関する組織要件への準拠を、ユーザーが行う必要あり
          • カスタマー管理キーを使用すると、KMSキーへのアクセス許可があるアカウントのユーザーのみ、関数の環境変数を表示または管理できる
    • クライアント側の暗号化を使用し、転送中のデータを保護
      • セキュリティ強化のため、転送中暗号化ヘルパーを有効にし、転送中保護のため環境変数をクライアント側で暗号化
  • 環境変数の暗号化設定方法
    • AWS KMSを使用し、Lambdaでサーバー側およびクライアント側の暗号化に使用するカスタマー管理キーを作成
    • Lambdaコンソールで、環境変数の暗号化設定を行う
    • コンソール暗号化ヘルパーを有効にし、クライアント側の暗号化を行うことで、転送中データを保護(オプション)
      • コンソール暗号化ヘルパーを有効にする各環境変数に対し、環境変数の横にあるEncryptを選択
      • 転送時に暗号化するKMSキーとして、最初作成したカスタマー管理キーを選択
      • 実行ロールのポリシーをコピー
        • このポリシーは、環境変数を復号するアクセス許可を関数の実行ロールに付与
      • 環境変数を暗号化する関数にコードを追加
    • 保管中の暗号化に使用するカスタマー管理キーを指定(オプション)
      • カスタマー管理キーとして、最初に作成したカスタマー管理のキーを選択
    • アクセス許可を設定
      • サーバー側暗号化でカスタマー管理キーを使用する場合、関数の環境変数の表示/管理を許可するIAMユーザー/ロールにアクセス許可を付与
        • LambdaのKMSキー操作に必要なアクセス許可
          • kms:ListAliases
            • Lambdaコンソールでキーを表示(Lambdaの管理ポリシーから提供)
          • kms:CreateGrant、kms:Encrypt
            • 関数でカスタマー管理キーを設定
          • kms:Decrypt
            • カスタマー管理キーで暗号化された環境変数を表示および管理
            • Decryptアクセス許可を持たないユーザーは、引き続き関数を管理できるが、Lambdaコンソールで環境変数を表示または管理できない
            • ユーザーが環境変数を表示できないようにするには、デフォルトキー、カスタマー管理キー、またはすべてのキーへのアクセスを拒否するステートメントをユーザーのアクセス許可に追加
        • IAMポリシー例: キーARNによるアクセスの拒否
          • "Effect": "Deny"
          • "Action": ["kms:Decrypt"]
          • "Resource": "arn:aws:kms:リージョン:アカウントID:key/キーARN"
      • クライアント側の暗号化を有効にする場合、関数にkms:DecryptAPIを呼び出すためのアクセス許可が必要
        • 上記ポリシーを関数の実行ロールに追加

おわりに

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