search
LoginSignup
0

posted at

updated at

Organization

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)

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
0