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

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

はじめに

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

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

複数AWSアカウントで、普段使用しないリージョンへの不正アクセスが報告された
- AWS OrganizationsのSCP(Service Control Policy)で、管理下のAWSアカウントの特定リージョンへのアクセスを拒否するよう制限をかける
  - SCPは、アカウントに対し最低限の禁止ルールをガードレールとして設定する、事前に適用範囲を絞って十分に検証が必要
  - ※ IAMアクセス制御を用いて、使わないリージョンのAWSサービスを使えない状態に設定可能だが、
    - それぞれのリージョンにおけるIAMリソース制限を設定するのは、手間がかかり設定漏れが発生する可能性あり
- SCP設定例: 指定されたリージョン以外のアクセスを拒否
  - 承認されたAWSリージョンregionA、regionB以外は、アクセス不可
  - 例外的に、regionA、regionB以外のグローバルサービスorganizations、pricingはアクセス可
  - 例外的に、ロールroleX、roleYはregionA、regionB以外にアクセス可
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideRegionA",
            "Effect": "Deny",
            "NotAction": [
                "organizations:*",
                "pricing:*",
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "regionA",
                        "regionB"
                    ]
                },
                "ArnNotLike": {
                    "aws:PrincipalARN": [
                        "arn:aws:iam::*:role/roleX",
                        "arn:aws:iam::*:role/roleY"
                    ]
                }
            }
        }
    ]
}
```

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

すべてのAWSリージョンに対し、AWSリソースの意図しない呼び出しを通知したい
- AWS CloudTrailが記録したユーザ操作履歴を使用し、取得された監査ログにリソースの不正利用が含まれていたら通知する仕組みを実装
  - CloudTrail証跡をすべてのリージョンに適用
    - CloudTrailコンソールで、証跡情報の設定ページのapply to all regionsにyesを選択
      - SDKまたはAWS CLIを使用する場合、IsMultiRegionTrailをtrueに設定
  - 証跡をすべてのリージョンに適用すると、CloudTrailによって証跡設定がレプリケーションされ、新しい証跡が作成される
  - CloudTrailは、各リージョンでログファイルの記録と処理を行い、すべてのAWSリージョンでアカウントアクティビティを含むログファイルを単一Amazon S3バケットおよび単一CloudWatch Logsロググループに配信
  - オプションのAmazon Simple Notification Service(SNS)トピックを指定した場合、単一SNSトピックに配信されたすべてのログファイルについてSNS通知を配信
- Amazon GuardDutyの脅威検出機能を使用し、AWSリソースの不正利用にすぐ気づくようにする
  - Amazon GuardDutyは、セキュリティ脅威リスクを検知・可視化
  - 悪意のあるIPアドレス、異常検出、機械学習などの統合脅威インテリジェンスを使用した脅威検知
  - CloudFormationのStackSetsを利用するため初期設定が必要

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

VPCインターフェイスエンドポイント作成時、特定AZ(アベイラビリティーゾーン)のサブネットを選択したい
- 考慮事項
  - インターフェイスエンドポイントを作成し、AWS PrivateLinkサービスに接続する場合
    - ENI(Elastic Network Interface)が起動された同じAZ内のサブネットを選択する必要あり
    - 異なるアカウントにおいて、同じAZ IDが同じAZ名にマッピングされるとはかぎらない
      - 例えば、同じサブネットsubnetXが配置されたAZが
        
        アカウントAではap-northeast-1aとしてマッピング
        
        アカウントBではap-northeast-1bとしてマッピング
  - AWSアカウント内にインターフェイスエンドポイントを作成する場合
    - 選択できるAZは、VPCのNLB(ネットワークロードバランサー)で有効になっているAZと一致
    - VPCコンソールが、AZのマッピングを自動的に実行
    - VPCのNLBで、AZが有効になっていない場合、Service not supported in this Availability Zoneエラーが表示される
- 設定方法
  - VPCのNLBで有効になっているAZを確認する、コマンド例:
    aws ec2 describe-vpc-endpoint-services --service-names com.amazonaws.vpce.us-east-1.vpce-svc-xxxxx
  - コマンド結果から、AZap-northeast-1bのサブネットが選択可能であることが分かる
```
{
    "ServiceDetails": [
        .............................
        "ServiceName": "com.amazonaws.vpce.us-east-1.vpce-svc-xxxxx",
        "VpcEndpointPolicySupported": false,
        "Owner": "##########",
        "AvailabilityZones": [
            "ap-northeast-1b"
        ],
        ..............................
}
```

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

AWS CLIによるAWSリソースへのアクセスで、MFAトークンによる認証を強制したい
- 考慮事項
  - MFAデバイスを用いた、AWSアカウントとリソースの保護が推奨されている
  - AWS CLIでMFAデバイスを使用しリソースを操作する場合、一時セッションを作成する必要あり
  - MFAデバイスのARN
    - MFAハードウェアデバイス使用時の例: GAHT12345678
    - 仮想MFA使用時の例: arn:aws:iam::123456789012:mfa/user
  - ※ 注意: Universal Second Factor(U2F)セキュリティキーは、AWS Management Consoleのみ利用できる
    - 回避策として、仮想MFAデバイスを使用
  - ※ 注意: AWS CLIコマンド実行中にエラーが発生した場合、最新バージョンのAWS CLIを使用しているか確認してください
- 一時認証情報の取得方法
  - AWS CLIコマンドsts get-session-tokenを実行
    $ aws sts get-session-token --serial-number MFAデバイスのARN --token-code トークンコード
  - 一時認証情報と有効期限(デフォルトは12時間)が出力される
```
{
    "Credentials":{
        "SecretAccessKey":"secret-access-key",
        "SessionToken":"temporary-session-token",
        "Expiration":"expiration-date-time",
        "AccessKeyId":"access-key-id"
    }
}
```
  - ※ sts get-session-tokenコマンドの--duration-secondsオプションを使用し、有効期限(秒単位)を指定可(900秒(15分)から129600秒(36時間))
    - ルートユーザーの認証情報を使用している場合、900秒(15分)から3600秒(1時間)
- 一時認証情報の使用方法
  - 環境変数に一時認証情報を設定し使用
    Linux: export AWS_ACCESS_KEY_ID=example-access-key-as-in-previous-output export AWS_SECRET_ACCESS_KEY=example-secret-access-key-as-in-previous-output export AWS_SESSION_TOKEN=example-session-token-as-in-previous-output Windows: set AWS_ACCESS_KEY_ID=example-access-key-as-in-previous-output set AWS_SECRET_ACCESS_KEY=example-secret-access-key-as-in-previous-output set AWS_SESSION_TOKEN=example-session-Token-as-in-previous-output
  - 再度get-session-tokenコマンドを呼び出す場合、環境変数設定を解除
    Linux: unset AWS_ACCESS_KEY_ID unset AWS_SECRET_ACCESS_KEY unset AWS_SESSION_TOKEN Windows: set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= set AWS_SESSION_TOKEN=
  - 名前付きプロファイルで一時認証情報を使用
    - ユーザーホームディレクトリの.awsフォルダー配下のcredentialsファイルを編集
    - MFA認証によりコマンドを発行するため、新しいプロファイル設定を追加
      [mfa] aws_access_key_id=example-access-key-as-in-returned-output aws_secret_access_key=example-secret-access-key-as-in-returned-output aws_session_token=example-session-Token-as-in-returned-output
    - 認証情報の有効期限が切れたら、get-session-tokenコマンドを再度実行し、戻り値を環境変数またはプロファイルに設定
    - ※ ヒント: get-session-tokenコマンド出力からexpirationをチェックし、再認証を求めるようなスクリプトまたはcronジョブをバックグラウンドで実行することを検討してください
    - ※ AWS CLIがconfigureコマンドにより設定済みの場合、既に永続的なIAMユーザー認証情報が存在するため、IAMユーザーはMFA認証なしでコマンドを実行する
      .aws/credentials
      
      [default] aws_access_key_id=example-access-Key-for-an-IAM-user aws_secret_access_key=example-secret-access-key-for-IAM-user
      - ※ 注意: 永続的なIAM認証情報でmfa_serialパラメータは使用できない
    - AWS CLIコマンドの--profileオプションで、プロファイルを指定可能
      - コマンド例1: デフォルトのプロファイル認証情報では、MFA認証が要求されない
        $ aws s3 ls
      - コマンド例2: MFA認証設定済みのプロファイルを指定すると、MFA認証が要求される
        $ aws s3 ls --profile mfa
- ※ MFA認証を使用し特定APIアクションを実行するよう、ユーザーに要求できる
  - IAMポリシーで、aws:MultiFactorAuthPresentまたはaws:MultiFactorAuthAge条件を使用

分野5: データ保護

AWS Well-Architected Tool(AWS WA Tool)のデータを保護したい
- ※ AWS WA Toolは、AWSのベストプラクティスを使用してアーキテクチャをレビュー/測定するため、一貫したプロセスを提供するクラウドサービス
  - ベストプラクティスは、AWSソリューションアーキテクトがビジネスソリューション構築における長年の経験に基づいて開発
  - このフレームワークは、時間の経過とともにニーズに合わせ拡張可能な設計を実装するためのガイダンスを提供
- ※ AWS WA Toolは、製品のライフサイクル全体を通じて次のことを支援
  - 決定事項のドキュメント化を支援する
  - ベストプラクティスに基づいてワークロードを改善するための推奨事項を提供
  - ワークロードの信頼性、安全性、効率性、費用対効果の向上
- AWSの責任共有モデルは、AWS Well-ArchitectedToolのデータ保護にも適用される
  - AWSは、すべてのAWSクラウドを実行するグローバルインフラストラクチャを保護する責任がある
  - ユーザーは、このインフラストラクチャにホストされているコンテンツを保護する責任がある
    - AWSアカウントのクレデンシャルを保護
    - IAMを用いて、ユーザーに職務遂行に必要な最小権限のみ与える
- 保管中の暗号化
  - AWS WA Toolによって保存されるデータは、保存時に暗号化される
- 転送中の暗号化
  - AWS WA Toolとの間で送受信されるデータは、転送中に暗号化される
- AWSはAWS WA Toolから収集されたデータをどのように使用するか
  - AWS Well-Architectedチームが、AWS WA Toolサービスの改善に使用
  - 個別のユーザーデータは、AWSアカウントチームに共有され、ユーザーのワークロードとアーキテクチャの改善に使用される
  - AWS Well-Architectedチームは、ワークロードのプロパティと各質問に対し選択された選択肢へのみアクセスできる
  - AWSは、AWS WA Toolの収集データをAWS外部と共有しない
- AWS Well-Architectedチームがアクセスできるワークロードプロパティ
  - ※ ワークロードは、リソースおよびビジネス価値をもたらすコード(顧客向けアプリケーションやバックエンドプロセスなど)の集まりを指す
  - ワークロード名
  - レビューオーナー
  - 環境
  - 地域
  - アカウントID
  - 業種
- AWS Well-Architectedチームがアクセスできないワークロード
  - ワークロードの説明
  - アーキテクチャの設計
  - 任意の入力されたメモ

おわりに

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

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

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

はじめに

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

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

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

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

分野5: データ保護

おわりに

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