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

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

はじめに

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

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

• インシデント調査のためEC2インスタンスにSSH接続したいが、ポート22アクセスが許可されていない
  • AWS Systems Managerで、Session ManagerのSSH接続を有効にする
    • Session ManagerのマネージドノードとなるEC2インスタンスで、ポート22のインバウンドアクセス許可不要
  • SSH接続を有効にする手順
    • SSHサーバーがEC2インスタンスで実行されていることを確認
    • SSM Agentのバージョン2.3.672.0以降がEC2インスタンスにインストールされていることを確認
      • マネージドノードとしてアクティベートしたオンプレミスサーバー、エッジデバイス、仮想マシン(VM)にSession Managerを使用する場合、アドバンストインスタンス層を使用する必要あり
    • SSHクライアントを使用しマネージドノードに接続するローカルマシンで、以下の手順を実行
      • Session Managerプラグイン1.1.23.0バージョン以降がインストールされていることを確認
      • SSH設定ファイルを更新し、Session Managerセッションを開始し、接続を介してすべてのデータを転送するプロキシコマンドを実行できるようにする
        • Linuxの場合、SSH設定ファイル~/.ssh/configに以下を追加

          # SSH over Session Manager
          host i-* mi-*
            ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
          

        • Windowsの場合、SSH設定ファイルC:\Users\username\.ssh\configに以下を追加

          # SSH over Session Manager
          host i-* mi-*
            ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p"
          

      • マネージドノードへの接続に使用するPrivacy Enhanced Mail証明書(PEMファイル)または公開キーを作成/確認
        • マネージドノードにすでに関連付けされたキーでなければならない
          • EC2インスタンスの場合、インスタンス作成時に作成または選択したキーペアファイル
        • プライベートキーファイルへのアクセス許可を設定し、ユーザーのみ読み取り可能に制限
          chmod 400 my-key-pair.pem
        • SSHセッション開始時、コマンドに証明書またはキーへのパスを指定
  • Session ManagerによるSSH接続のアクセス許可
    • IAMポリシーで、IAMユーザー/グループ/ロールがSession ManagerでSSH接続を確立するための権限を付与
      • 方法1: IAMコンソールで、Session Managerのエンドユーザーポリシーで作成したクイックスタートポリシーに要素を追加
        • "Effect": "Allow"
        • "Action": "ssm:StartSession"
        • "Resource": [
          • "arn:aws:ec2:region:アカウントID:instance/インスタンス名",
          • "arn:aws:ssm:*:*:document/AWS-StartSSHSession"]
      • 方法2: AWS Management Console、AWS CLI、AWS APIを使用し、インラインポリシーをユーザーポリシーにアタッチ

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

• EC2インスタンスへのSSH接続により実行されるコマンドを監視したい
  • AWS Systems ManagerのSession Managerが適用されたマネージドノードにセキュアシェル(SSH)接続を有効に設定
    • インバウンドポートを開いたり、踏み台ホストを維持したりすることなく、マネージドノードへ接続できる
      • セキュリティグループでポート22のインバウンドアクセスが許可されている場合、不要となるため削除
    • AWSアカウントのユーザーにAWS CLIを使用する許可を付与する必要あり
    • SSH接続するユーザーはSecure Copy Protocol(SCP)を使用し、ローカルマシンとマネージドノード間でファイルコピーも可能
  • IAMポリシーを使用し、IAMユーザー/グループ/ロールがSession ManagerでSSH接続を確立することを明示的に許可/拒否できる
  • セッションデータのログ記録に、Amazon S3またはAmazon CloudWatch Logsを使用
    • ログ記録は、ポートフォワードまたはSSH、を介して接続するSession Managerのセッションでは使用できない
      • 理由は、SSHはすべてのセッションデータを暗号化、Session ManagerはSSH接続のトンネルとしてのみ機能するため

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

• 社内からVPCにVPNにより接続しているが、インターネット接続が不安定
  • AWS Direct Connect接続で、ローカルネットワークからVPCへのAWS VPNを確立
    • Direct Connect+VPN接続の利点
      • 一貫性のあるスループットレベルを確保
      • データ保護の暗号化アルゴリズムを実現
      • インターネット経由のVPNより速くて安全
  • 接続方法
    • Direct Connect接続を作成
      • Direct Connect接続用のパブリック仮想インターフェイスを作成
      • Prefixes you want to advertise(アドバタイズするプレフィックス)で、カスタマーゲートウェイデバイスのパブリックIPアドレスを入力
        • 必要に応じて、アドバタイズするネットワークプレフィックスを追加
      • ※ 注意: すべてのAWSパブリックIPアドレスのプレフィックスがパブリック仮想インターフェイスに送信される
        • AWSマネージドVPNエンドポイントのパブリックIPアドレスも含まれる
    • 新しいVPN接続を作成
      • 上述カスタマーゲートウェイのパブリックIPアドレスを指定
        • カスタマーゲートウェイは、ボーダーゲートウェイプロトコル(BGP)と自律システム番号(ASN)を使用し設定可能
      • VPCに接続するようにVPNを設定

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

• AWSアカウントAのAmazon EC2 Auto Scalingグループのインスタンスで、別AWSアカウントBのカスタマー管理キーを用いて暗号化したAmazon EBSを使用したい
  • カスタマー管理キーが、Auto Scalingグループと異なるアカウントにある場合、キーへのクロスアカウントアクセスを許可するキーポリシーを組み合わせて付与する必要あり
    • アカウントBで、カスタマー管理キーのキーポリシーを作成
      • ステートメント1、アカウントAのIAMユーザーまたはロールにキー操作許可を付与
      • ※ AWSアカウントにキーへのフルアクセスを付与しても、IAMユーザーまたはロールにキーへのアクセス権は付与されない
        • "Effect": "Allow"
        • "Principal": {"AWS": ["arn:aws:iam::アカウントAのID:root"]}
        • "Action": [
          • "kms:Encrypt",
          • "kms:Decrypt",
          • "kms:ReEncrypt*",
          • "kms:GenerateDataKey*",
          • "kms:DescribeKey"]
        • "Resource": "*"
      • ステートメント2、アカウントAのIAMユーザとロールに独自アクセス許可を委任できるアクセス許可を付与
        • "Effect": "Allow"
        • "Principal": {"AWS": ["arn:aws:iam::アカウントAのID:root"]}
        • "Action": ["kms:CreateGrant"]
        • "Resource": "*"
    • つぎに、KMSキー関連のアクセス許可をAuto Scalingのサービスにリンクされたロールに委任する許可を作成
      • aws kms create-grant \
      • --region リージョン \
      • --key-id arn:aws:kms:リージョン::key/KMSキーのARN \
      • --grantee-principal arn:aws:iam::アカウントA:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling \
      • --operations "Encrypt" "Decrypt" "ReEncryptFrom" "ReEncryptTo" "GenerateDataKey" "GenerateDataKeyWithoutPlaintext" "DescribeKey" "CreateGrant"

分野5: データ保護

• ALBのターゲットグループに登録された複数インスタンス間の通信を暗号化し保護したい
  • ALB経由のトラフィックは自動的な暗号化をサポートされず、送信元EC2インスタンスでデータ暗号化してから、送信先EC2インスタンスに送信する必要あり
  • AWSではすべてのタイプのEC2インスタンス間において安全でプライベートな接続を提供する
  • ただし、インスタンス間の転送中のトラフィックを自動暗号化をサポートするのは、一部インスタンスタイプのみ
    • ネットワークのパフォーマンスには影響しない
  • インスタンス間でトラフィック暗号化のサポートにおける制限事項
    • サポート対象インスタンスタイプが限定される
      • Nitro Systemハードウェアのオフロード機能をサポートする場合、AEAD 256ビット暗号化アルゴリズムを用いて自動暗号化
    • 各インスタンスは、同じリージョンに存在する必要あり
    • 各インスタンスは、同じVPC内またはピア接続されたVPCに存在する必要あり
    • トラフィックが、仮想ネットワークデバイスもしくはサービス(ロードバランサーやTransit Gatewayなど)を通過してはいけない

おわりに

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

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