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


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

はじめに

早速、今回も「こんな時どうする」の追記です。
精査はしていますが、過去と似たような項目を取り上げる可能性あります、悪しからず。

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

  • EC2インスタンスで使用されていないポートが攻撃された、稼働中システムを止めずにすぐ対処したい
    • セキュリティグループのインバウンドルールから問題のポート番号を削除

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

  • S3バケットのアクセスログに「認証失敗」「HTTP Referer情報」を含め記録したい

    • S3サーバーアクセスログを使用し、S3リクエストをログ記録
  • S3バケットのアクセスログに「IAM/ユーザー特定情報」「クロスアカウントログ」を含め記録したい、かつログファイルを暗号化したい

    • AWS CloudTrailを使用し、S3のAPIコールをログ記録
  • Amazon GuardDutyによる監視で、特定EC2インスタンスから頻繁に誤検知(false positive)の通知発生するため、監視対象から除外したい

    • 信頼できるIPリストに、問題EC2インスタンスのIPアドレスを追加し、Amazon GuardDutyに適用
    • ※ 信頼できるIPリストのアップロード数は各リージョンのAWSアカウントにつき1つのみ
    • ※ Amazon GuardDutyとは
      • セキュリティの観点から脅威リスクを検知するマネージドサービス
      • 分析のソースに下記を利用、メタデータの連続ストリームを分析
        • VPC Flow Logs
        • AWS CloudTrail Event Logs
        • DNS Logs
      • 統合脅威インテリジェンスを使用し脅威を認識

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

  • VPC内複数コンテナ間で相互TLS認証による通信を行いたい
    • ACMプライベートCA(証明機関)を使用し、下位CAを作成
    • ACM(AWS Certificate Manager)を使ってプライベート証明書を作成、すべてのコンテナに適用する
    • ※ ACMプライベートCAとは、プライベート証明書のライフサイクルを簡単かつ安全に管理するマネージドサービス
      • 自社プライベートCAを先行投資やメンテナンスコストをかけず運用でき、可用性の高いプライベートCAを得られる

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

  • AWSアカウントを保護したい

    • AWSアカウントのルートユーザーまたはIAMユーザーに対しMFA(多要素認証)を有効に
  • EC2 Linuxインスタンスにログインしたい

    • キーペアによる認証でログイン
    • キーペアには、プライベートキーとパブリックキーが含まれる
      • パブリックキーは、EC2インスタンス内に保管
      • プライベートキーは、ユーザー自身が保管
  • セキュリティ監査の実施タイミングが不明

    • 定期的監査
    • 従業員が退職するなど組織変更があった場合
    • 1つ以上のAWSサービスを使用しなくなった場合(不要になったアクセス許可を削除するため重要)
    • AWSアカウントでソフトウェアの追加/削除があった場合(EC2インスタンスのアプリケーション、AWS OpsWorksスタック、AWS CloudFormationテンプレートなど)
    • 権限のない人がアカウントにアクセスした疑いがある場合

分野5: データ保護

  • S3バケットのオブジェクトに対し、KMSキーを用いたサーバー側暗号化(SSE-KMS)を強制するポリシーを作成したい
    • ポリシーで下記Statementを定義
    {
      ... ...
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Condition": {
        "StringNotEquals":{
           "s3:x-amz-server-side-encryption":"aws:kms"
        }
      }
    }
  • S3バケットのオブジェクトに対し、S3バケットキーを用いたサーバー側暗号化(SSE-S3)を強制するポリシーを作成したい
    • ポリシーで下記2つのStatementを定義
    {
      ... ...
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    },
    {
      ... ...
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }
  • 独自のキーマテリアルをインポートしているKMSキー(カスタマー管理キー)を毎年更新したい
    • 新しいKMSキーを作成し
    • 新しいキーマテリアルをインポート
    • 既存のKMSキーのエイリアスを新しいKMSキーにマッピング
    • ※ KMSキー(カスタマー管理キー)の種類とローテーション
      • カスタマー管理の対称KMSキー
        • キーマテリアルをAWS KMSで生成
          • 1年ごとの自動更新を設定可
        • キーマテリアルをAWS CloudHSMクラスターで生成(KMSカスタムキーストア機能を使用)
          • 自動更新不可、要手動更新
        • 独自のキーマテリアルをインポート
          • 自動更新不可、要手動更新
      • カスタマー管理の非対称KMSキー
        • キーマテリアルはAWS KMS HSMでのみ生成可能
          • 自動更新不可

おわりに

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