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

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

はじめに

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

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

• インシデントの自動修復を行いたい
  • AWS Step Functionsを使用し、ITおよびセキュリティのオートメーション化が可能
  • ※ Step Functionsはローコードのビジュアルワークフローサービスで、以下の用途で使用
    • 分散アプリケーションの構築
    • ITおよびビジネスプロセスの自動化
    • AWSサービスを利用したデータと機械学習のパイプラインの構築
  • ※ ワークフローにより、障害、再試行、並列化、サービス統合、可観測性などが管理され、デベロッパーはより価値の高いビジネスロジックに集中できる
    • Step Functionsにより、マニュアルによる介入を必要とせず、ビジネスのニーズに合わせ自動的にスケールするワークフローを作成できる
    • 失敗したタスクの再試行を自動的に行い、ワークフローのエラーを管理できるエクスポネンシャル・バックオフを実行できる
      • エクスポネンシャル・バックオフとは、リクエスト処理が失敗した後、現実的に成功しそうな程度のリトライを、許容可能な範囲で徐々に減らしつつ継続するアルゴリズム
    • ワークフローが進行する前に、人間の介入が必要になる場合、分岐ロジックを定義し、定義した量を超えるリクエストのみが人間の承認を必要とし、他のすべてのリクエストは自動的に完了できる
      • 人による承認が必要な場合、特定のステップでワークフローを一時停止し、応答を待ち、応答を受信した後にワークフローを続行できる
  • Step Functionsによるオートメーションワークフローのタイプ
    • ITオートメーション
      • 複雑/反復的で時間のかかるタスクのオートメーション化により、日常業務を迅速かつ一貫性を持たせながらラージスケールで完了できる
        • ソフトウェアのアップグレードとパッチ適用
        • 脆弱性対応のためのセキュリティ更新プログラムのデプロイ
        • インフラストラクチャの選択
        • データの同期
        • サポートチケットのルーティング
      • インシデントの自動修復
        • SSHポートの露出
        • ディスクの枯渇
        • S3バケットへ公開アクセス権付与
      • AWS CloudFormation StackSetsのデプロイをオートメーション化
    • セキュリティオートメーション
      • IAMユーザーおよびユーザーアクセスキーが公開されているシナリオへの応答を自動化
      • アクションを特定のARNに制限したり、他のアクションを適用するなど、定義されたポリシーアクションに従って、セキュリティインシデントレスポンスを自動修正
      • フィッシングメール受信後数秒以内に従業員に警告
    • ヒューマン承認
      • 機械学習モデルのトレーニングをオートメーション化
        • 受け取った応答に基づきモデルを自動的にデプロイまたは拒否する前に、データサイエンティストによるモデルのマニュアル承認を要求できる
      • センチメント分析に基づき、受け取った顧客からのフィードバックのルーティングを自動化し、否定的なセンチメントを持つものはすぐにエスカレーションしマニュアルレビューを行う
        • センチメント分析とは、Web上に存在する口コミやブログの書き込み、SNSの投稿といったテキスト情報から個人が抱いている感情を分析する手法

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

• 複数のAWSアカウントからCloudTrailログファイルを受け取りたい
  • 複数のAWSアカウントのログファイルを1つのS3バケットに配信するようにCloudTrailを設定できる
    • 例えば、4つのAWSアカウントID、111111111111、222222222222、333333333333、444444444444に対し
    • ログファイルをすべて、アカウント111111111111に属するバケットへ配信できる
  • CloudTrailの設定例
    • 配信先バケットが配置されるアカウント111111111111で、CloudTrailを有効にするため証跡を作成
      • その他のアカウントでは、この時点でまだCloudTrailを有効にしない
    • 配信先バケットのバケットポリシーを更新し、CloudTrailにクロスアカウントのアクセス権限を付与
    • その他アカウント222222222222、333333333333、444444444444で、CloudTrailを有効に
      • アカウント111111111111に属する同じバケットを使用するようにCloudTrailを設定

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

• EC2インスタンスが「Client.InternalError: Client error on launch」エラーにより終了する
  • ボリュームの暗号化/復号に使用するAWS KMSキーへの必要なアクセス許可がない場合発生
    • ルートEBSボリュームが暗号化されているが、復号用のKMSキーにアクセスする権限がない
    • AMIのブロックデバイスマッピングで指定されたスナップショットが暗号化されているが
      • 復号するためのKMSキーへのアクセス権限がない
      • または、復号されたボリュームを暗号化するためのKMSキーへのアクセス権限がない
  • ※ EC2が終了した理由を確認する方法
    • EC2コンソールhttps://console.aws.amazon.com/ec2/を使用
      • ナビゲーションペインでInstancesを選択し、インスタンスを選択
      • 最初のタブで、State transition reason(状態遷移の理由)の横にある理由を確認
    • AWS Command Line Interfaceを使用
      • aws ec2 describe-instances --instance-id instance_id
      • コマンドによって返されたJSONレスポンスで、StateReasonレスポンス要素の値を確認
    • AWS CloudTrailを使用
      • CloudTrailイベント履歴でイベントを確認

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

• CloudTrailの特定証跡のみログファイルをS3バケットに書き込めるよう許可したい
  • S3バケットポリシーに、awsグローバル条件キーaws:SourceArnを追加し、CloudTrailの1つまたは複数の特定証跡のみS3バケットに書き込めるように制限する(ベストプラクティス)
  • ※ S3バケットとオブジェクトはデフォルトでプライベートのため、リソース所有者(バケットを作成したAWSアカウント)のみ、バケットとそれに含まれるオブジェクトにアクセスできる
    • リソース所有者は、アクセスポリシーを記述することで他のリソースおよびユーザーにアクセス権限を付与できる
  • ※ CloudTrail証跡ログファイルを受け取るS3バケットを作成/変更する際は、バケットポリシーを変更する必要あり
    • ベストプラクティスとして、CloudTrailログ用に専用S3バケットを使用
    • ログファイル配信用S3バケットは、CloudTrailに必要なアクセス権限が付与されるため、リクエスタ支払いバケットとしては設定できない
  • バケットポリシーでCloudTrailに必要なフィールド
    • 許可されたSID
    • バケット名
    • CloudTrailのサービスプリンシパル名
    • ログファイルが格納されるフォルダ名
      • バケット名
      • プレフィックス(指定した場合)
      • AWSアカウントID
    • aws:SourceArn条件キー
      • ログ格納対象の証跡ARN(または証跡ARNの配列)
      • ※ 既存証跡が使用するS3バケットポリシーも忘れずaws:SourceArn条件キーを追加
  • S3バケットポリシー例
    • Statement1
      • "Effect": "Allow"
      • "Principal": {"Service": "cloudtrail.amazonaws.com"}
      • "Action": "s3:GetBucketAcl"
      • "Resource": "arn:aws:s3:::myBucketName"
    • Statement2
      • "Effect": "Allow"
      • "Principal": {"Service": "cloudtrail.amazonaws.com"}
      • "Action": "s3:PutObject"
      • "Resource": "arn:aws:s3:::myBucketName/[optionalPrefix]/AWSLogs/myAccountID/*"
      • "Condition"

        "StringEquals": {
            "s3:x-amz-acl": "bucket-owner-full-control",
            "aws:SourceArn": "arn:aws:cloudtrail:region:myAccountID:trail/trailName"
        }
        

分野5: データ保護

• KMSキーをすぐ使用できなくしたい
  • KMSキーからインポートされたキーマテリアルを削除
    • キーマテリアルが削除されると、KMSキーのキーステータスがインポート保留中に変わり、KMSキーを暗号化オペレーションで使用することができなくなる
    • ※ インポートされたキーマテリアルの有効期限が切れても、AWS KMSにより削除される
    • ※ キーマテリアルを削除してもKMSキーは削除されず、KMSキーに同じキーマテリアルを再インポートすることで、KMSキーを再度使用できる
  • インポートされたキーマテリアルを削除した場合、またはAWS KMSが有効期限切れのキーマテリアルを削除した場合、AWS KMSはCloudTrailログにエントリを記録
  • キーマテリアルを削除する方法
    • AWS Management Consoleを使用
    • またはAWS KMS APIを使用
      • HTTPリクエストを直接行う
      • AWS SDK
      • AWS Command Line Interface(AWS CLI)
      • AWS Tools for PowerShell
  • ※ KMSキーそのもの(キーマテリアルでなく)を削除した場合は、操作を破棄できない
    • KMSキー削除をスケジュールし、有効期限切れまでの必要な待機期間が終了すると、AWS KMSはキーマテリアルとKMSキーに関連付けられたすべてのメタデータを削除

おわりに

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

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