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

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

はじめに

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

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

• EC2 Linuxマネージドノードに不正侵入が報告された、既存のPowerShellスクリプトの調査ツールを使用し確認したい
  • AWS Systems ManagerのRun Command機能を使用し、LinuxマネージドノードでPowerShellスクリプトを実行
    • aws:runPowerShellScriptプラグインまたはAWS-RunPowerShellScriptコマンドドキュメントのいずれかと、PowerShell Coreを使用し、Linuxマネージドノードで PowerShellスクリプトを実行できる
  • 事前準備
    • Linuxマネージドノードに接続し、OSに合わせPowerShell Coreをインストール
    • Linuxマネージドノードで使用可能なコマンドを確認
      • pwshコマンドを使用しPowerShellを起動
      • Get-Commandコマンドレットで使用可能なコマンドを確認
  • コンソールを使用し、LinuxマネージドノードでPowerShellスクリプトの実行方法
    • AWS Systems Managerで、[Run Command]を選択
    • [Command document(コマンドのドキュメント)]リストで、AWS-RunPowerShellScriptドキュメントを選択
    • [Command parameters(コマンドのパラメータ)]セクションで、使用するPowerShellコマンドを指定
    • [Targets(ターゲット)]セクションで、オペレーションを実行するマネージドノードを選択
    • [タイムアウト(秒)] に、コマンドの実行全体が失敗するまでにシステムが待機する秒数を指定
    • [レート制御]の場合
      • [Concurrency(同時実行数)]で、コマンドを同時実行するマネージドノードの数または割合を指定
      • [Error threshold(エラーのしきい値)]で、エラーが何回発生したらコマンドの実行を停止するか指定
    • (オプション)コマンド出力をファイル保存する場合は、[Output options]の[Write command output to an S3 bucket]ボックスを選択
      • S3バケットへの書き込みアクセス許可の対象は、タスクを実行するIAMユーザーではなく
        • EC2インスタンスの場合、インスタンスに割り当てられたインスタンスプロファイル
        • オンプレミスマシンの場合、IAMサービスロール
    • [SNS Notifications(SNS 通知)]セクションで、コマンドの実行状態に関する通知を受け取る場合、[Enable SNS notifications(SNS 通知を有効にする)]チェックボックスをオンにする
    • [Run(実行)]を選択

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

• アプリケーションが、不具合などにより繰り返しAWSリソースを大量に呼び出していないか監視したい
  • AWS CloudTrail Insightsを使用し、異常なアクティビティを追跡
  • ※ CloudTrail Insightsは、機械学習(ML)モデルを使用し、AWSアカウントおよびリージョン内のCloudTrail書き込みイベントを分析することで、異常なアクティビティを検出
    • 異常なイベントは、以前確立された動作パターンまたはベースラインの範囲から逸脱するAWS API呼び出しの量として定義
      • API呼び出しの時間ベースの傾向を考慮し、ワークロードの変化に応じて最適ベースラインを適用することにより、通常の運用パターンの変化に適応する
    • 大量のAWS API呼び出しにより請求コストが予想外に増加する前に、異常に気付き迅速に対処できる
  • ※ CloudTrail Insightsにより特定できる異常なアクティビティ
    • リソースプロビジョニングの急上昇
    • IAMアクションのバースト
    • 定期的なメンテナンスアクティビティのギャップ
  • ※ 検出された異常なアクティビティの確認方法
    • コンソールにCloudTrail Insightsイベントが表示される
    • Amazon CloudWatch Events
    • Amazon S3バケット
    • オプションでAmazon CloudWatch Logsグループに配信できる

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

• EC2インスタンスから、ゲートウェイVPCエンドポイント経由で、S3バケットに接続できない
  • ネットワークアクセス、またはVPCからS3への接続許可のセキュリティルールに問題ないか、次のようにリソースと設定を確認
    • リージョンの設定
      • VPCエンドポイントを使用してアクセスできるのは、ゲートウェイVPCエンドポイントと同じリージョンにあるS3オブジェクトに制限される
    • VPCのDNS設定
      • VPCコンソールで、DNS解決を有効に設定
    • ルートテーブルをS3に設定
      • VPCコンソールで、「ゲートウェイVPCエンドポイントを使用するS3」へのルートが指定されているか確認
    • セキュリティグループのアウトバウンドルール
      • EC2コンソールで、S3へのトラフィックが許可されたアウトバウンドルールが存在するか確認、なかったら以下のいずれかを追加
        • 「ゲートウェイVPCエンドポイントに関連付けられたプレフィックスリストID」へのトラフィックを許可するアウトバウンドルール
        • 送信先が「S3のVPCエンドポイント」に設定されているアウトバウンドルール
    • ネットワークACLルール
      • VPCコンソールで、ネットワークACLを選択
        • [インバウンドルール]ビューで、エフェメラルTCPポート(動的ポート)1024-65535のS3からのインバウンドリターントラフィックが、ルールにより許可されているか確認
        • [アウトバウンドルール]ビューで、HTTPSポートのS3へのトラフィックが、ルールにより許可されているか確認
    • ゲートウェイVPCエンドポイントポリシー
      • ※注意: エンドポイントは、現在クロスリージョンリクエストをサポートしないため、エンドポイントがバケットと同じリージョンにあることを確認
        • get-bucket-locationコマンドを使用し、バケットの場所を見つける
      • VPCコンソールで、エンドポイントポリシーにより、S3バケットまたはIAMユーザーへのアクセスがブロックされていないか確認
    • S3バケットポリシー
      • バケットポリシーにより、ゲートウェイVPCエンドポイントとVPCからのアクセスが許可されているか確認
      • ※注意: バケットポリシーは、「VPCのインスタンスに関連付けられた」特定のパブリックIPアドレスやElastic IPアドレスからのアクセスのみを制限できる
        • インスタンスに関連付けられたプライベートIPアドレスに基づくアクセスは制限できない
      • プロキシサーバーを使用する場合、必ずサーバー経由のVPC接続を許可
        • S3にプロキシサーバーを使用しない場合、S3バケットへのアクセスでプロキシサーバーを迂回
        • export no_proxy = mybucket.s3.リージョン.amazonaws.com
    • IAMポリシー
      • インスタンスからS3バケットへのアクセスに使用される、IAMユーザーかロールを選択し、S3にアクセス許可があるか確認
    • AWS CLIの設定
      • aws configureコマンドを使用し、デフォルトのAWSリージョンを設定
      • または、AWS CLIコマンドでその都度--regionオプションを設定
        • デフォルトのリージョンを指定したくない場合
        • デフォルトのリージョンを上書きしたくない場合
    • AWS SDKの設定
      • ゲートウェイVPCエンドポイントを使用しS3バケットにリクエストを行う際、正しいリージョンを使用するようSDK(またはクライアントオブジェクト)を設定

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

• EC2 Linuxインスタンスへのリモートアクセスを保護したい
  • AWSクラウドにLinux踏み台ホスト(Linux Bastion Hosts on AWS)を置き、リモートアクセスのセキュリティを保護する
    • 踏み台ホストを置くことで、VPCのプライベートサブネットとパブリックサブネットに置かれているLinuxインスタンスに安全にアクセスできる
    • Linux踏み台ホストのインスタンスはパブリックサブネットにデプロイ
    • EC2 Auto Scalingグループを利用し、踏み台ホストインスタンスの数を指定値に保持できる
    • セキュリティ強化のために、シェルの履歴ログのリモート保管用にAmazon CloudWatch Logsを設置
  • 踏み台ホストの設置例
    
    ※引用元: https://aws.amazon.com/jp/quickstart/architecture/linux-bastion/
    • 2つのAZにまたがる可用性の高いアーキテクチャ
    • パブリックサブネットとプライベートサブネットで構成されたVPC
    • インターネットアクセスをサポートするインターネットゲートウェイ
      • 踏み台ホストがトラフィックを送受信するために使用される
    • マネージドNATゲートウェイ
      • プライベートサブネット内のリソースへ、アウトバウンドのインターネットアクセスを提供
    • Linux踏み台ホストは、パブリックサブネットごとに配置されElastic IPアドレスが与えられる
      • パブリックサブネットとプライベートサブネットのEC2インスタンスに対し、インバウンドのSSHアクセスを許可
    • インバウンドアクセスを細かく制御するためのセキュリティグループ
    • Amazon EC2 Auto Scalingグループ
      • インスタンスの数を設定可能
    • 踏み台ホストインスタンスの数分のElastic IPアドレスセット
      • Auto Scalingグループによりインスタンスが再起動する場合、新しいインスタンスと再度関連付けられる
    • Linux踏み台ホストのシェル履歴ログ用Amazon CloudWatch Logsロググループ

分野5: データ保護

• Amazon Simple Email Serviceのデータを保護したい
  • Amazon SESは、ユーザー自身のEメールアドレスとドメインを使用し、Eメールを送受信するための、簡単で費用対効果の高いEメールプラットフォーム
  • 保管中の暗号化
    • Amazon SESはAWS KMSと統合され、S3バケットに書き込むメールを暗号化
    • Amazon SESはクライアント側の暗号化を使用し、S3に送信前にメールを暗号化
    • つまり、S3からメールを取得した後、自身でコンテンツを復号する必要あり
      • AWS SDK for JavaおよびAWS SDK for Rubyは、復号処理用クライアントを提供
  • 転送中の暗号化
    • Eメール送信者からAmazon SESへの転送で使用されるセキュリティプロトコル
      • Amazon SES APIを使用する場合(直接またはAWS SDK経由)
        • すべての通信はAmazon SESのHTTPSエンドポイントによりTLSで暗号化される
          • TLS 1.2、TLS 1.1、TLS 1.0のみサポート
      • Amazon SES SMTPインターフェイスを使用する場合
        • TLSを使って接続を暗号化する必要あり
        • Amazon SESは、TLSで暗号化された接続を確立するため、2 つのメカニズムをサポート
          • STARTTLS
            • 暗号化されていない接続を暗号化された接続にアップグレードする方法
            • 様々なプロトコルに対応したバージョンが存在し、「RFC 3207」に定義
            • Amazon SESはTLS 1.2、TLS 1.1、TLS 1.0、SSLv2Hello をサポート
          • TLS Wrapper(SMTPSまたはハンドシェイクプロトコル)
            • 最初から暗号化された接続を開始する方法
            • Amazon SES SMTPエンドポイントはTLSネゴシエーションを実行しない
            • TLSを使用しエンドポイントに接続し、通信全体でTLSの使用を継続するのはクライアントの役割
            • 古いプロトコルだが、数多くのクライアントが今もサポート
            • Amazon SESはTLS 1.2、TLS 1.1、TLS 1.0をサポート
    • Amazon SESから受信者への転送で使用されるセキュリティプロトコル
      • Amazon SESは、TLS接続にTLS 1.2、TLS 1.1、TLS 1.0をサポート
      • デフォルトで、Amazon SESは常に受信メールサーバーへの安全な接続を確立しようとする
      • 安全な接続を確立できない場合、Amazon SESは平文メッセージを送信
      • 設定セットにTLS接続を要求するようにAmazon SESを設定できる
        • PutConfigurationSetDeliveryOptionsAPIオペレーションを使用し、設定セットのTlsPolicyプロパティをRequireに設定
        • AWS CLIのコマンド例
          aws sesv2 put-configuration-set-delivery-options --configuration-set-name 設定セットの名前 --tls-policy REQUIRE
        • この設定セットを使用しEメールを送信する場合、Amazon SESは、安全な接続を確立できる受信Eメールサーバーに対してのみメッセージを送信
  • エンドツーエンドの暗号化
    • Amazon SESを使用し、「送信者によってS/MIMEまたはPGPプロトコルにて暗号化された」メッセージを送信できる
    • メッセージを復号するために必要なパブリックキーを有する受信者のみ、コンテンツを表示できる
    • S/MIMEで暗号化されたEメール送信のためサポートされるMIMEタイプ
      • application/pkcs7-mime
      • application/pkcs7-signature
      • application/x-pkcs7-mime
      • application/x-pkcs7-signature
    • PGPで暗号化されたEメール送信のためサポートされるMIMEタイプ
      • application/pgp-encrypted
      • application/pgp-keys
      • application/pgp-signature

おわりに

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

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