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

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

はじめに

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

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

• Amazon GuardDutyにより、「Stealth:IAMUser/CloudTrailLoggingDisabled」メッセージが通知された
  • CloudTrailの追跡が無効化されたことを示すCloudTrail管理イベントで、認証情報が侵害された可能性あり
    • 不正侵入者がユーザーのAWSリソースへアクセスしている間、活動の痕跡を消すためロギングを無効化した可能性
    • このメッセージは、証跡情報の削除または更新が成功することによってトリガーされる場合がある
    • GuardDutyに関連付けられている証跡のログを保存するS3バケットが削除された場合もトリガーされる
  • 侵害されたAWS認証情報の修復
    • 影響を受けたIAMエンティティと使用されたAPIコールを特定
      • 使用されたAPIコールは、結果詳細にAPIとして表示される
      • IAMエンティティ(IAMユーザーまたはIAMロール)とその識別情報は、結果詳細のリソースセクションに表示される
        • 関連するIAMエンティティのタイプは、ユーザータイプフィールドで特定できる
        • IAMエンティティの名前は、ユーザー名フィールドに表示される
        • 結果に関連するIAMエンティティのタイプは、使用されたアクセスキーIDからも特定できる
          • AKIAで始まるアクセスキーIDは、IAMユーザーまたはAWSアカウントルートユーザーの長期的な認証情報
          • ASIAで始まるアクセスキーIDは、AWS STSオペレーションを使用して作成される一時的な認証情報
            • 短時間しか存在せず、AWS Management Consoleで表示または管理することはできない
            • ロールにより使用された場合、ユーザー名フィールドにロールの名前が表示される
            • CloudTrailログエントリのsessionIssuer要素を確認し、キーがどのようにリクエストされたか特定できる
    • IAMエンティティのアクセス許可を確認
      • IAMコンソールを開き、使用されたエンティティのタイプに応じてユーザータブまたはロールタブを選択し、検索フィールドに特定した名前を入力し影響を受けたエンティティを見つける
      • アクセス許可タブとアクセスアドバイザータブを使用し、そのエンティティの有効なアクセス許可を確認
    • IAMエンティティの認証情報が正当に使用されたか確認
      • アクティビティが意図的なものか認証情報のユーザーに確認
        • たとえば、以下を行ったか確認
          • GuardDutyの結果に表示されたAPIオペレーションの呼び出し
          • GuardDutyの結果に表示された時刻におけるAPIオペレーションの呼び出し
          • GuardDutyの結果に表示されたIPアドレスからのAPIオペレーションの呼び出し
      • AWS認証情報の正当な使用と確認できた場合、GuardDutyの結果は無視できる
      • 確認できない場合、特定のアクセスキー、IAMユーザーのIDとパスワード、またはAWSアカウント全体に対する侵害が行われた可能性あり

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

• AWSアカウントの大量アクティビティログに対し、リアルタイム分析と可視化および永続的な保存を実現したい
  • Amazon KinesisとAmazon OpenSearch Serviceを使用し、ログデータを収集、処理、分析する
    • このログ分析ソリューションは、バッチデータとストリーミングデータ両方の収集、取り込み、処理、ロードを実行し、既に使用している分析システムで処理済みデータをほぼリアルタイムで利用できる
    • 信頼性、拡張性、費用対効果を持っており、データボリュームの変化に応じて自動スケール可能で、IT管理はほとんど必要ない
  • 設定方法
    • データソースでKinesis Agentを設定し、収集されたデータをAmazon Kinesis Firehoseに継続的に送信
    • Kinesis Firehoseを使用し、エンドツーエンドのデータ配信ストリームを作成
    • エージェントからの配信ストリームは、Amazon OpenSearch Serviceに送信できる
    • Amazon Kinesis AnalyticsでSQLクエリを使用し、受信ログデータを処理
    • Kinesis AnalyticsからAmazon OpenSearch Serviceに処理済みデータをロードし、データのインデックスを作成
    • Kibanaを使用し、処理済みデータの分析と可視化を実行

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

• 組織の複数アカウントでAWSリソースを安全に共有したい
  • AWS Resource Access Manager(AWS RAM)を使用し、1つのAWSアカウントで作成したAWSリソースを他のAWSアカウントと安全に共有できる
  • AWS RAMでリソース共有可能な範囲
    • 組織内のAWSアカウント間
    • AWS Organizations内の組織単位(OU)間
    • IAMロールおよびIAMユーザーとの間
  • AWS RAMでサポートされるリソースタイプ
    • トランジットゲートウェイ
    • サブネット
    • AWS License Managerのライセンス設定
    • Amazon Route 53のResolverルール
  • AWS RAMを使用する利点
    • 運用のオーバーヘッドを削減
      • リソースを複製する場合、すべてのアカウントにプロビジョニングするための運用コスト
    • セキュリティと一貫性を実現
      • 単一ポリシーと権限セットを使用し、共有リソースのセキュリティ管理を簡素化
      • リソースを複製する場合、すべてのアカウントで同じポリシーとアクセス許可の実装コスト
    • 可視性と監査性を提供
      • Amazon CloudWatch、AWS CloudTrailと統合し、共有リソースの使用状況を監視することで、共有リソースとアカウントに対する包括的な可視性を提供

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

• AWS OrganizationsのSCP設定でS3アクセスを拒否しているが、特定のAWSアカウントAのみS3アクセスを許可したい
  • S3アクセスを拒否しないSCPを適用した新しい組織単位(OU)を作成し、アカウントAを新しいOUに移動する
  • ※ SCPは、アカウントのアクセス許可の上限を指定するJSONポリシーで、SCPによるアクセス許可の特徴:
    • SCPは、組織の一部であるアカウントが管理するIAMユーザーとロールのみに影響し、リソースベースのポリシーには直接影響しない
      • 組織外のアカウントに属するIAMユーザーやロールにも影響しない
    • SCPは、メンバーアカウントのIAMユーザーとロールのアクセス許可を制限し(ルートユーザーを含む)、管理アカウントのIAMユーザーやロールには影響しない
    • IAMユーザーとロールには、適切なIAMアクセス許可ポリシーを使用しアクセス許可を付与する必要あり
      • IAMアクセス許可ポリシーがアタッチされていないユーザーは、たとえSCPにより許可されたサービスとアクションであっても、アクセスできない
      • IAMアクセス許可ポリシーによりアクセス許可されたアクションであっても、SCPによって許可されていないまたは明示的に拒否されている場合、そのアクションを実行できない
    • SCPは、アタッチされたアカウントのすべてのIAMユーザーやロール(ルートユーザーを含む)に影響するが、例外として制限されないタスクおよびエンティティが存在
      • 管理アカウントによって実行されるすべてのアクション
      • サービスにリンクされたロールにアタッチされたアクセス許可を使用して実行されるすべてのアクション
      • rootユーザーとしてEnterpriseサポートプランに登録する
      • rootユーザーとしてAWSサポートレベルを変更する
      • 信頼された署名者にCloudFrontプライベートコンテンツの機能を提供する
      • Amazon LightsailメールサーバーおよびEC2インスタンスの逆引きDNSをルートユーザーとして設定する
      • 一部の AWS 関連サービスでのタスク
        • Alexa Top Sites
        • Alexa Web Information Service
        • Amazon Mechanical Turk
        • Amazon Product Marketing API
    • SCPは、サービスにリンクされたロールに影響しない
      • サービスにリンクされたロールを使用し、他のAWSサービスをAWS Organizationsと統合でき、SCPによる制限は受けない
    • ルートのSCPポリシータイプを無効にすると、そのルートのすべてのAWS OrganizationsエンティティからすべてのSCPが自動的にデタッチされる
      • AWS Organizationsエンティティには、組織単位、組織、およびアカウントが含まれる
      • ルートのSCPを再度有効にすると、そのルートはすべてのエンティティに自動的にアタッチされるデフォルトのFullAWSAccessポリシーに戻る
        • SCP無効化前にAWS OrganizationsにアタッチされていたすべてのSCPは失われ、自動復旧されない、手動で再度アタッチはできる
    • アクセス許可の境界(高度なIAM機能)とSCP両方存在する場合、アクセス許可の境界、SCP、およびIDポリシーによって、アクションの許可が決定される

分野5: データ保護

• KMSのカスタマー管理キーを自分で制御/管理したい(AWSもアクセスできない)、かつ不正使用防止と簡単アクセスを実現したい
  • AWS CloudHSMを使用する
    • VPC内で実行され、EC2インスタンスで実行されているアプリケーションでHSM(ハードウェアセキュリティモジュール)を簡単に使用できる
      
      ※ 引用元: https://aws.amazon.com/jp/cloudhsm/
  • CloudHSMの特徴
    • AWSは、HSMアプライアンスの状態およびネットワークの可用性を監視するが、キーへのアクセス権は持たない
      • ユーザーが、HSMおよび暗号化キーの生成と使用をコントロールする
    • アプリケーションのパフォーマンスが向上する(AWSワークロードと近接しているため)
      • HSMは、EC2インスタンスの近くにあるAmazonデータセンターに配置されるため、アプリケーションとHSM間のネットワークレイテンシーはオンプレミスのHSMより低い
    • 複数のアベイラビリティーゾーン(AZ)で利用できる
    • 不正使用防止策が施されたハードウェアでの安全なキーストレージ
      • アプリケーションは、HSMクライアントソフトウェアによって確立された相互認証済みSSLチャネルを使用しHSMに接続
    • HSMはVPC内にあり、他のAWSネットワークから分離されている
      • CloudHSMでは、HSMへのアクセス管理に標準のVPCセキュリティコントロールを使用できる
      • 責任の分離とロールベースのアクセスコントロールが可能

おわりに

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

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