【AWS初学者向け】AWS認定資格直前対策

AWS Configのproactiveモード。proactiveは「先を見越した」という意味であることから理解する。

下記二つが実際にパブリックへのAllowを検出するタイプ。

• Policy:S3/BucketAnonymousAccessGranted
  • S3をインターネットに公開した
• Policy:S3/BucketPublicAccessGranted
  • 全てのAWSユーザにアクセスを許可した

下記二つはパブリックアクセスブロックの無効化を検出するタイプ。

• Policy:S3/AccountBlockPublicAccessDisabled
  • アカウントレベルでパブリックアクセスブロックを無効化した
• Policy:S3/BucketBlockPublicAccessDisabled
  • バケットレベルでパブリックアクセスブロックを無効化した

実際にバケットポリシーやACLで明示的にAllowされていない限り，S3はパブリックへAllowされている訳ではない点に注意する。

できない。IAM Access Analyzerは外部からの意図しない通信が発生していないかを解析するツール。

CloudTrailのAPI証跡のうち異常なパターンを検出するサービス

GuardDuty

• CloudTrail
• VPC Flow Logs
• DNS Logs
• Kubernetes監査ログ

CloudTrailのログ保管先は厳しいセキュリティ要件が求められる。そのため，適当なACLを設定しているバケットにログを保管しないことを担保するために，S3バケットのACLをGetする権限が必要になると考える。

principalは*しかサポートしていないこと

APNネットワークと協力する。自社だけで完結するとAWSのカスタマーアグリーメントに違反してしまう可能性がある。

• WAF
• AWS Shield
• SG

署名付きURL または署名付きCookie経由の通信のみを許可する設定

どちらも用いられる。KSKは「ゾーンの公開鍵に対して署名を行う秘密鍵」に対応する公開鍵であり，ZSKは「データに対して署名を行う秘密鍵」に対応する公開鍵である。

DNS応答が正式な権威サーバから返ってきたことを検証するための仕組み。あるDNSレコードXに対するDNSSECを構築したいケースを考える。

• ゾーンの管理者は秘密鍵と公開鍵（=ZSK）のペアを作成する
• 公開鍵は署名（=KSKによる署名）と共に公開しておく
• レコードXを秘密鍵で署名する
• レコードXに問い合わせがあった際は，レコードXに加えて上で作成した署名も同時に返す
• レコードXの問い合わせ元は，ゾーンで公開されている公開鍵を照らし合わせてレコードXを検証する

ただし，上のフレームではKSKの正当性は担保されない。そこで，DNSSECでKSKの正当性を信頼の連鎖で担保する。具体的には，KSKのハッシュ値を親ゾーンに渡し，親ゾーンは渡されたハッシュ値を自身のZSKで署名してハッシュ値と共にDSレコードで公開する。親ゾーンは同様にZSKの公開鍵をKSKによる署名と共に公開する。この信頼をTLDまで続けることで，子のKSKの妥当性が担保される。

親ホストゾーン

• 所望のホストゾーンでDNSSECを有効化する
• DSレコードの値をコピーする
• 親ゾーンであるドメインレジストラ（Route53の場合はRoute53）でDSレコードを追加する

外部ID。「混乱した代理問題」と呼ばれるリスクに対応するために利用されるIDのこと。混乱した代理問題というのは，信頼関係側で「アカウントID」推測容易なRole名を扱っている場合に，意図しないアカウントからのアクセスも許可してしまう問題のことを指す。

あるAWSアカウントXが外部サービスYにassumeしてもらうroleを作成し，信頼関係を結んだとする。このrole名は人間にとって分かりやすい名前をつけることが多いため，悪意のある攻撃者が下記情報を盗むことは比較的容易である。

• AWSアカウントXのアカウント名
• role名
• 外部サービスY

すると，悪意のある攻撃者は「AWSアカウントXのroleが自分のroleであるかのように」AWSアカウントXのroleを外部サービスYに提供し，信頼関係を結んでもらうことができる。すると，悪意のある攻撃者がroleを利用することができるようになってしまうという問題。

この問題に対応するため，信頼関係を結ぶ際に一意のIDをconditionに指定することができる。このIDを外部IDという。

• Cognitoユーザプール
  • 認証を司る。ID/Passを管理するディレクトリサービス。
• Cognito IDプール
  • 認可を司る。英語ではFederated Identitiesと称され，Cognitoの中核を担うサービス。

• Identity Provider（Cognitoユーザプール or SNS認証 or 独自プロバイダ）で認証しトークンを取得する
• Federated Identity（Cognito IDプール）でトークンの検証をする
• Federated Identity（Cognito IDプール）がIAMのSTSで一時的キーを発行して返す

• CMK（カスタマーマスターキー）：CDKを暗号化・復号する鍵
• CDK（カスタマーデータキー）：データを暗号化・復号する鍵

CMKを「カスタマーマネジメントキー」と誤解しないように注意。

※ 2022年5月にAWS管理のCMKのローテーション間隔が3年から1年に変更された

2022年5月以前は，AWS管理のCMKを3年未満でローテーションしたい場合は，カスタマー管理のCMKに変更する必要があった。なお，現在でもCMKを1年未満でローテーションしたい場合は手動でローテーションを行う必要がある。

ELBで暗号化を終端し，新しく暗号化通信を開始する。具体的には，下記手順を行う。

• ACMで外部証明書を発行してELBにインポートする
• ELBで外部証明書を用いて暗号化通信を終端する
• ACMで内部証明書を発行してEC2にインポートする
• 内部証明書用いた暗号化通信をELBで開始してEC2で終端する

• 既存のS3バケットでサーバ側の暗号化設定を有効化する
• COPYコマンドで既存のオブジェクトを上書きする

暗号化したS3バケット上ではオブジェクトの書き込み時に暗号化が行われるため，暗号化されていないオブジェクトを上書きすることで全てのオブジェクトが暗号化されることが保証される。

KMSのオペレーションで付与される追加情報。シークレットではないが，データの完全性や暗号化の認証をサポートする情報になっている。

顧客が提供するキーマテリアルをインポートする顧客管理CMKを利用する。AWS提供のキーマテリアルだと有効期限を指定することができない。

AWSが発行する期限付きの公開鍵。顧客が用意した鍵を安全に送受信するために利用される。

• ラッピングキーとインポートトークンを発行する
• 鍵をラッピングキーで暗号化してインポートトークンと一緒にAWSに送信する

• Key：CMKのID
• GranteePrincipal：許可を与える対象
• Operations：許可を与える内容
• Constrains：Grantが有効になる条件
• RetiringPrincipal：Grantを無効化させられる対象

Constrainsで利用される。具体的には，下記宣言をサポートしている。

• EncryptionContextSubset：暗号化コンテキストが検査対象の中に含まれていればOK
• EncryptionContextEquals：暗号化コンテキストが検査対象に完全一致すればOK

例えば，EncryptionContextSubset {"Department": "Finance", "class": "critical"} に対して，

• {"Department": "Finance", "class": "critical", "customer": "12345"}：OK
• {"Department": "Finance"}：NG

となり，EncryptionContextEquals {"Department": "Finance", "class": "critical"} に対して，

• {"Department": "Finance", "class": "critical"}：OK
• {"Department": "Finance", "class": "critical", "customer": "12345"}：NG

となる。例えば，EBSのIDを暗号化コンテキストで指定すると，特定のEBSに対してGrantできる。

SSE-KMSのデフォルト仕様で異なるデータキーを利用するようになっている。

111122223333のルートユーザおよび111122223333に含まれる全てのプリンシパル

IAMユーザの作成が不要になる点。

1. オンプレのSAMLプロバイダーのメタ情報をダウンロードする
2. AWS SSOで上記メタデータをインポートして外部IdPの設定を行う
3. SSOユーザ及びグループの作成（登録メールアドレス宛にパスワード設定リンクが送られる）
4. SSOユーザ及びグループに対する権限セット（IAMポリシー）作成および紐付け
5. オンプレのSAMLプロバイダーによるフェデレーションを許可する信頼関係をもつIAM Roleを作成する
6. AWS SSOで上記で作成したRoleのARNを指定

これらの手順により，3.で作成したSSOユーザがログインに成功すると，5.で作成したRoleに4.で設定したポリシーがアタッチされた状態でマネコンにログインすることができるようになる。

S3のVaultLockは二段階になっている。一段階目ではLock状態と同じ挙動を示すが，実際にロックは行われていない。この状態で，ユーザはLock状態のテストをおこなうことができる。テストが完了し次第，実際にLockを行うためには24時間以内にCompleteVaultLockをcallする必要がある。もし，24時間を超えたた場合やAbortVaultLockをcallした場合は，Lockがキャンセルされる。

aws sts get-session-token --serial-number {MFAデバイスARN} --token-code {ワンタイムパスワード}

を利用する

下記のようにBoolIfExistsを利用する。Boolを使うと「MFAを設定していない場合は評価自体が行われずノールックでDenyとなる」ため，既存ユーザでMFAを設定していないケースが存在する場合を考慮するとBoolIfExistsを利用した方がベター。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllWhenMFAIsNotPresent",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {"aws:MultiFactorAuthPresent": false}
            }
        }
    ]
}

• AWS上のAD ConnectorでオンプレのADにプロキシして認証要求を行う
  • ネットワークのレイテンシーを考慮する必要がある
• AWS Managed Microsoft ADを構築し，（一方向の）信頼関係を構築する
  • 同一リージョンで稼働するためレイテンシーはほぼ考慮不要

SSM Documentで必要となるモジュールを内部でS3バケットからGetするため。

信頼される側が信頼する側の権限を利用できるイメージ。「ほらよっ」と鍵を投げつけるイメージ。例えば，AWS上でオンプレ上のADを利用したい場合は，ADがAWSを信頼する（鍵を投げつける）必要がある。

AWSのre:Post上の言葉を用いると下記のようになる。信頼する側のドメインが信頼される側で解決できるようにフォワーダを設定する必要があるイメージも持っておくとよい。

一方向の信頼シナリオでは、信頼されたドメイン側のユーザーアカウントには、信頼するドメイン側にあるリソースへのアクセス許可が付与されます。

AWS Managed Microsoft AD と既存のオンプレミス AD ドメインの間に信頼関係を作成する方法を教えてください。

• 一方向：EC2・RDS SQL Server・FSx
• 双方向：Workspaces・Chime・Connect・SSO・QuickSight・マネコン等

オンプレのADとは異なるドメインでManaged Microsoft ADを作成し，AWS上のManaged Microsoft ADからオンプレ上のADへ一方向の信頼関係を構築する。

AWS→オンプレの信頼関係では，AWSがオンプレを信頼するので，オンプレ上でユーザを作成すればAWS上に反映されるし，AWS上でユーザを作ればオンプレ上には反映されない。これが本来あるべき姿。オンプレ→AWSの信頼関係も構築してしまうと，AWS上でユーザを作るとオンプレ上に反映されてしまうため，管理が煩雑になってしまい，不適切。オンプレのADとAWS上のADをシームレスに結合したい場合は双方向の信頼関係を結ぶとよいのかもしれない。

AWS→オンプレの信頼関係構築では，下記のような操作を行うイメージを持つ。

• オンプレ側でAWSのドメインに対するクエリはAWSに転送しなくてはならないので，条件付きフォワーダをオンプレ側に構築する
• オンプレ側のドメインコントローラでAWS上のADを信頼する。この際，ウィザードに従って設定を進めていけば，信頼の方向を明示できる。

EC2上にADを構築する。Managed Microsoft ADは使わない。RDSはManaged Microsoft ADを使う必要があるため，この方法ではRDSは使用できない。他にも，AD Connectorを利用する方法もある。

• フォレスト信頼：ルートドメイン同士の信頼（サブドメインも含めて全て信頼）
• 外部信頼：サブドメイン同士の信頼（一部のサブドメイン同士のみで信頼）

• Resource Access Manager（RAM）でCloudHSMが属するサブネットIDを他のAWSアカウントに共有
• CloudHSMクラスターにアタッチするSGで他のアカウントが利用するプライベートIPを許可

指定できない。CIDRを指定する。

ConditionフィールドのPrincipalArnを利用する。Principalフィールドは定義されていない

同一リージョン同一VPCで特定のインスタンスタイプを利用し，仮想ネットワークを経由しない通信であれば，デフォルトで暗号化できる。

オンプレ側。現行の証明書が切れる前にセカンダリの証明書をインポートすることができる。

CloudHSM。S3はVPC内アクセス可能にするためには工夫が必要だが，CloudHSMはデフォルトで実現可能。

できない。

リージョンごとに作る必要はない。マルチリージョンの証跡を一つのS3に保存すればよい。

sourceArnを利用する。sourceArnはAWSサービス，principalArnはIAMプリンシパルのイメージ。

CMKでS3のサーバサイド暗号化を有効化する。S3のデフォルト暗号化はKMSを利用しない点に注意。

• アクセス先のリージョンでSTSエンドポイントでSTSトークンを取得する
• STSのグローバルエンドポイントでSTSトークンを取得する

2023年8月のアップデートにより，SGをアタッチできるようになった。

• SSE-KMSでS3バケットキーを有効化する
  • バケットレベルのキーによりオブジェクトに対して一意のデータキーを生成する
  • S3の内部で一定期間使われるためS3からKMSへのリクエストトラフィックを減らすことができる
• SSE-Cで暗号化されたS3オブジェクトを取得する操作がないこと
  • SSE-Cで暗号化されたオブジェクトを取得するためにはリクエストの中で同じ暗号化キーを指定する必要がある

両者とも，不必要なトラフィックは減らすという思想に基づいている。

解析しない。静的な設定上，外部に対して意図しないアクセス許可が与えられていないかを確認することができるツール。

CMKのこと

できない

GuardDutyは単発のイベントからセキュリティイベントを検知するが，Detectiveは過去のログやイベントを参照して時系列的に可視化することが可能。

IAMロールを利用する。外部サービスとの権限連携にはロールを利用するとおさえておく。

90日

稼働中に行う。停止すると揮発するため。

必要ない。S3のデフォルト暗号化の際にいつも指定していないことを思い出す。

インスタンスプロファイル

設定できない。代わりにSource/Destinationチェックを無効にする。

GLB登場以前は，ネットワークアプライアンスを導入するために細かなルーティング設定や冗長化構成を考慮する必要があった。一方，GLBはELBの一種であるため，ルーティング設定も柔軟に行えるだけでなく，冗長性も担保されている。

必要ない。暗号化時に必要で，復号時のCDKは複合して得られるため，Decrypt権限が必要。

90日以内のアクティビティであること。90日を経過するとS3にログを転送する必要がある。

• カスタマー管理CMKのキーポリシーでKMSの暗号化/復号権限とGrant権限を別アカウントに付与する
• 別アカウント側でAutoScalingグループのサービスロールにcreate-grantすることでCMKが利用できる

可能

検知可能

Trusted Adviser

Instance Metadata Service

IMDSv2はトークンに基づくセッションを利用する

• インスタンスプロファイルで"ec2:MetadataHttpTokens": "required"を設定する
• AWS CLIのaws ec2 modify-image-attributeのimds-supportオプションでv2.0を指定する

Configルールを利用してコンプライアンスのリソース評価を行う

AWS

有している

CloudHSMを利用する。KMSのAWS管理型のキーを利用すると，即座に削除できない。

有用でない。あくまでも認証情報の設定状況をレポートする機能しかない。

DNSリゾルバがRoute53を利用していない場合は検知できない。

できる。既存のVPC Flow Logsは編集できないため，新しくVPC Flow Logsを作成してログの形式をカスタム形式で指定する。その際，pkt-srcaddrとpkt-dstaddrを含めるように設定する。