記事の目的

意外とややこしく奥深いAWS Certified Security – Specialty試験対策の中で

AWS若干ワカル自分も新しく知ったことを記載しました。

知らない範囲がどこかの炙り出し程度にご活用ください

記事の対象者

SAAに受かったぐらいの人

SCSを受けたいと思っている人

1-5年AWSに触れている人

注意

chatGPTと共にガーッと書いた記事なので、

記載が少し古くなっていたり、単語の間違いがあるかもですが、

そちらはご愛嬌で。

あくまで知らない、弱い範囲のざっくりとした炙り出し程度にご活用ください

程よくマニアックなことが書かれていることがこの記事の良いところだと思います

見出し

EC2関連
ファイルシステム関連
認証系
セキュリティ関連
DB関連
その他

EC2関連

AWS Systems Manager

フォレンジック分析

とは犯罪捜査における分析や鑑識

Session Manager

新しい秘密鍵は不要。

フォレンジックAMI

フォレンジックAMIはKMSによって暗号化、複合化されるのでポリシー権限が必要

EC2の使用されているキーペアを検索する楽な方法

aws ec2 describe-instances –query “Reservations[].Instances[].KeyName” | jq -r unique

Systems Manager Compliance

PatchBaselineOperationsに非準拠であるため、グラフで赤く表示など、コンプライアンスの表示が可能

REJECT トラフィック

「REJECTトラフィック」とは、ネットワーク通信において、特定のデータパケットや接続リクエストが拒否された状況を指します。

ネットワークインターフェース

プロミスキャスモードを備えていない

EBS

EC2に入っているEBSの秘密鍵を紛失したケース

authorized_keys の更新は公開鍵で実施する必要がある

そしてその際インスタンスは停止している必要がある

スナップショットの共有ルール

・スナップショットは、スナップショットが作成されたリージョンに制限されます。別のリージョンとスナップショットを共有するには、そのリージョンにスナップショットをコピーして、そのコピーを共有します。

・デフォルトの AWS マネージドキーで暗号化されたスナップショットを共有することはできません。

共有できるのは、

カスタマーマネージド型キー

を使用して暗号化されたスナップショットだけです。

・暗号化されていないスナップショットのみをパブリックに共有できます。

・暗号化されたスナップショットを共有する場合は、スナップショットの暗号化に使用するカスタマーマネージド型キーも共有する必要があります。

プロキシEC2

送信元、送信先のチェックを無効化する必要がある

ファイルシステム関連

S３

S3 パブリックアクセスブロックはアカウントまたは S3 バケットに適用される

バケットACL

バケットの個別のオブジェクトへのアクセス権を調整可能なもの

コンプライアンスモード

書き込みは一回、読み込みは複数を強制できる

ガバナンスモード

少しコンプライアンスモードが緩くなり、一部ユーザーは上書きなどが可能

Glacier

S3標準からGlacierに直接データを送信できる

24時間以内に移動をした方がいい。voltロックポリシーに引っかかる

Anonymous access granted

オブジェクトACL

オブジェクト ACL は、バケット所有者が所有していないオブジェクトへのアクセスを許可する唯一の方法です。

S3 オブジェクト所有権

–acl bucket-owner-full-controlを設定することで、バケットベースで所有権設定が可能。これであげてもらえたら完全な管理が可能になる。

バッチオペレーションジョブ

オブジェクトの暗号化が可能

EFS

認証系

SSO

マネコンへのアクセスを制限できる。

アプリケーションの認証周りは基本Cognitoを使用すると良い

SCP

マネージドSCP

これは変更できない

SCPはプリンシパルとNotPrincipal

をサポートしていない

ACM（Certifacate Manager）

→AWS Certificate Manager は EC2 インスタンスをサポートしていない

RAM

サブネットの共有が可能

CloudHSMのリソースを直接共有は難しい、サブネットやTGWが主に共有されるリソース

AWS IAM Identity Center

AM Identity Center導入を検討していて現在外部IdPを利用していないのであれば、

デフォルトでIdentityCenterディレクトリがあるのでこれを利用することが出来ます。

ルートユーザー

ルートユーザーのパスワードは変更できない

ルートユーザーに権限をアタッチメントもできない

AWSのABAC(タグに基づいたアクセス制御)の設計/運用

タグを用いて、アクセス可能なタグの設定を行うことで権限設定を行う形

権限セット　許可セット

AWS IAM Identity Center の 許可セット(Permission Set) は AWSアカウントへのアクセス権(など)を定義するリソース

アクセス権限セットは、1 つまたは複数の [IAM policies] (IAM ポリシー) のコレクションの定義を作成および維持するテンプレート

IAM Access Analyzer

IAMの現状の状況を見て、意図しないアクセス権限を保有していないかなどを検証できるツール

過去と今の違いを調べたいならconfigなどを使うのが良い

ロールの連鎖

ロールの連鎖は、AWS CLI または API を使用して 2 つ目のロールを引き受けるロールを使用する場合に発生します。たとえば、User1 に RoleA と RoleB を引き受けるアクセス許可があるとします。また、RoleA には RoleB を引き受けるアクセス許可があります。RoleA API オペレーションで User1 の長期的なユーザー認証情報を使用して AssumeRole を引き受けることができます。このオペレーションは RoleA の短期的な認証情報を返します。ロールの連鎖を行うには、RoleA の短期認証情報を使用して RoleB を引き受けます。

マネコンではロールの連鎖はできない

Called Via

ポリシー権限の設定で、DynamoDBやCloudFormationで設定可能

何経由で呼び出された場合の権限としての条件づけ

IAMポリシーと境界ポリシーの違い

IAMポリシーと境界ポリシーは、異なる用途を持つため、一般的には別々に管理・適用されます。具体的には、以下のように扱います。

IAMポリシー

IAMポリシーは、ユーザー、グループ、またはロールに直接アタッチされ、アクセス権限を定義するために使用されます。これらのポリシーは独立したJSONドキュメントとして作成され、AWSマネジメントコンソール、AWS CLI、またはAWS SDKを使用してIAMエンティティにアタッチされます。

境界ポリシー

境界ポリシー（Permissions Boundary）は、IAMユーザーまたはロールに適用される上限の権限を定義するために使用されます。境界ポリシーも独立したJSONドキュメントとして作成され、IAMユーザーやロールに対して適用されます。

Pass Role権限

Assume roleが特定のロールになる権限

Pass Roleが特定のAWS サービスに IAM ロールをパスするための権限

CloudFormationに権限を渡すときなど必要

SAMLメタデータファイル

SAMLメタデータファイル中身SAML (Security Assertion Markup Language) メタデータファイルは、XML形式で記述され、SAMLプロバイダー（IdPやSP）の構成情報を提供します。メタデータファイルには、プロバイダーのエンドポイントURL、証明書、サポートするプロトコルなどが含まれています。

EntityDescriptor: メタデータのルート要素で、entityID属性はプロバイダーの一意の識別子です。
IDPSSODescriptor: IdP（Identity Provider）の情報を含む要素です。protocolSupportEnumeration属性はサポートするSAMLプロトコルを示します。KeyDescriptor要素には署名用の証明書が含まれ、SingleSignOnService要素にはSSO（Single Sign-On）サービスのエンドポイントが記述されています。
SPSSODescriptor: SP（Service Provider）の情報を含む要素です。こちらもprotocolSupportEnumeration属性でサポートするプロトコルが示され、KeyDescriptor要素には署名用の証明書が含まれます。AssertionConsumerService要素にはAssertionを受け取るサービスのエンドポイントが記述されています。

このようなメタデータファイルを用いることで、IdPとSP間の設定や信頼関係を確立することができます。

VPC

VPCトラフィックミラーリング

DNSクエリログは保存されない

Route 53 リゾルバーのDNSログ機能の設定が有効

ADFS

ADFSはActive Directory Federation Servicesの略称

ADFSの構築手順

ADFS（Active Directory Federation Services）サーバーの構築は、IDおよびアクセス管理のために重要です。以下は、ADFSサーバーを構築する際に行う基本的な操作手順です。

1. 前提条件の確認

Windows Server がインストールされたマシン
ドメインコントローラー へのアクセス
SSL証明書 の準備

2. サーバーマネージャーの使用

ADFSの役割追加
- サーバーマネージャーを開き、「役割と機能の追加」をクリック。
- 「役割ベースまたは機能ベースのインストール」を選択し、インストールするサーバーを選択。
- 「Active Directoryフェデレーションサービス（ADFS）」の役割を選択し、必要な機能とともにインストール。

3. ADFSの構成

ADFS構成ウィザードの起動
- サーバーマネージャーで「通知」アイコンをクリックし、「ADFSの構成」を開始。
- 「フェデレーションサービスの構成」ウィザードが起動するので、以下の手順に従う。
フェデレーションサービスの構成
- 新しいフェデレーションサーバーファームの作成：最初のADFSサーバーの場合、新しいファームを作成します。
- SSL証明書の指定：事前に準備したSSL証明書を指定します。
- サービスアカウントの指定：フェデレーションサービスに使用するドメインユーザーアカウントを指定します。
- 構成データベースの指定：WID（Windows Internal Database）かSQL Serverのいずれかを選択します。
構成の完了
- 構成が完了したら、フェデレーションサービスのエンドポイントにアクセスして、正常に動作していることを確認します。

4. クライアントアクセス設定

ADFSエンドポイントの公開：必要に応じて、ADFSのエンドポイントを外部からアクセスできるようにします（リバースプロキシやWAPを使用）。

5. Relying Party Trust（信頼関係）の設定

リライングパーティートラストの追加：ADFSを利用してサービスに認証を提供するための信頼関係を追加します。

6. クレームプロバイダートラストの設定

必要に応じて、クレームプロバイダートラストを設定します。

7. テストと検証

設定が完了したら、テストユーザーを使用してログインを試み、正しく機能するか確認します。

これらの手順を順に実行することで、ADFSサーバーを正しく構築し、IDおよびアクセス管理のために使用することができます。

AWSでのADFS cognito SAML Microsoft Active directoryを用いた認証の構築方法

AWSでADFS（Active Directory Federation Services）とCognitoを使い、SAML（Security Assertion Markup Language）を通じてMicrosoft Active Directoryによる認証を構築する手順は以下の通りです。

前提条件

AWSアカウント
Active Directory環境とADFSのセットアップ
Cognito User Pool

手順

1. ADFSの設定

Relying Party Trustの追加
- ADFS管理コンソールを開き、「Relying Party Trusts」を選択し、新しいRelying Party Trustを追加します。
- ウィザードに従って以下の情報を入力します。
  - フェデレーションメタデータURL：AWSのCognito User PoolのSAMLエンドポイントのURL。
  - 証明書：AWSのCognito User Poolからダウンロードした証明書。
- 他の設定はデフォルトのまま進めます。
Claim Issuance Policyの設定
- Relying Party Trustsに対してClaim Issuance Policyを設定します。
- 「Issuance Transform Rules」に新しいルールを追加します。
  - Send LDAP Attributes as Claims：LDAP属性をSAMLアサーションとして送信します。
    - E-Mail-AddressesをName IDにマップします。

2. Amazon Cognitoの設定

Cognito User Poolの作成
- AWSコンソールにログインし、Cognitoを開きます。
- 新しいUser Poolを作成し、名前を付けます。
Identity Providerの設定
- User Pool内で「Federation」タブを選択し、「Identity Providers」を選択します。
- SAMLを選択し、以下の情報を入力します。
  - Metadata Document：ADFSのRelying Party Trustから取得したメタデータドキュメント。
  - Attribute Mapping：SAMLアサーションからの属性をCognitoのユーザー属性にマッピングします。
App Clientの設定
- User Pool内で「App Clients」を選択し、新しいクライアントを作成します。
- クライアント設定で、SAMLを許可する設定を有効にします。
Domainの設定
- User Pool内で「Domain Name」を選択し、新しいドメインを作成します。
- このドメインはユーザーがログインするためのエンドポイントとなります。

3. テストと検証

ADFSからのログインをテスト
- 設定が正しく行われているかを確認するため、CognitoのドメインURLにアクセスし、ADFSを通じてログインを試みます。
- 正しく設定されていれば、ADFSのログイン画面が表示され、認証後にCognitoのUser Poolにリダイレクトされます。
ユーザー属性の確認
- ログイン後、Cognitoのユーザー属性が正しくマッピングされていることを確認します。

これで、AWSでADFSとCognitoを使ったSAML認証の設定が完了します。問題が発生した場合、設定の各ステップを再確認し、ADFSやCognitoのログを確認することでトラブルシューティングを行います。

httpセキュリティヘッダー

HTTPセキュリティヘッダーは、ウェブアプリケーションのセキュリティを強化するために使用されるHTTPレスポンスヘッダーです。これらのヘッダーを使用することで、ブラウザの動作を制御し、様々な攻撃から保護することができます

Strict-Transport-Security (HSTS)

X-Frame-Options

X-Content-Type-Options

などがある

VPC

VPCフローログのカスタム

宛先と送信元のIPを入れたいときは、既存のフローログを削除し、srcipやtargetipを追加してあげる必要がある

Direct Connect

カスタマーゲートウェイと仮想プライベートゲートウェイの違い

カスタマーゲートウェイ（Customer Gateway, CGW）

役割: オンプレミス（物理的なデータセンターやオフィスネットワーク）に設置されるデバイスまたはソフトウェアで、クラウドネットワークとのVPN接続を確立する役割を持ちます。
設置場所: ユーザーのオンプレミスネットワーク内。
接続の種類: オンプレミスネットワークから仮想プライベートゲートウェイ（VGW）やトランジットゲートウェイ（TGW）へのVPN接続を確立します。
構成: ユーザーが管理し、必要なIPsec設定を行います。

仮想プライベートゲートウェイ（Virtual Private Gateway, VGW）

役割: AWSクラウド内のVPC（仮想プライベートクラウド）におけるVPN接続の終端ポイントとして機能します。これは、AWSのネットワークインフラの一部として提供されます。
設置場所: AWSクラウド内の特定のVPCにアタッチされます。
接続の種類: 仮想プライベートゲートウェイは、カスタマーゲートウェイからのVPN接続を受け入れ、VPC内のリソースと通信を可能にします。
構成: AWSマネジメントコンソールやAPIを使用して設定します。

具体的な違いのまとめ

設置場所:
- CGW: オンプレミスネットワークに設置。
- VGW: AWSクラウド内のVPCにアタッチ。
管理責任:
- CGW: ユーザーが管理し、設定。
- VGW: AWSが提供し、管理。
役割:
- CGW: オンプレミスネットワークとクラウドネットワークをつなぐVPN接続を確立。
- VGW: クラウド内のVPCへのVPN接続を受け入れ。

これにより、オンプレミスのネットワークとAWSクラウド内のネットワーク間で安全な通信が確立され、データ転送やリソースの利用が可能となります。

EventBridge

ルートユーザーのアクセスを監視可能

セキュリティ関連

CloudTrail

組織レベルの CloudTrail有効化

を行うと、組織レベルでcloudtrailの設定など不要となる。

AWS CloudTrailの「証跡」と「組織の証跡」の違い

AWS CloudTrailの「証跡」と「組織の証跡」の違いについて

CloudTrail証跡

範囲: 単一のAWSアカウント内のアクティビティを監視します。
作成と管理: 各アカウントで個別に設定します。個々のアカウント管理者が証跡を作成・管理します。
コスト: 各アカウントごとに証跡の料金がかかります。
利用シナリオ: 単一のアカウントでのアクティビティの監査やセキュリティ監視を行う場合に適しています。

組織の証跡（Organization Trail）

範囲: AWS Organizationsを使用して複数のアカウントにまたがるアクティビティを監視します。
作成と管理: AWS Organizationsの管理アカウントが組織全体の証跡を設定し、管理します。これにより、各アカウントで個別に証跡を設定する必要がなくなります。
コスト: 組織全体での監視ができるため、管理が簡素化されると共にコストの最適化が可能です。ただし、証跡のコストは組織全体での利用に基づきます。
利用シナリオ: 複数のアカウントを持つ大規模な組織で、全体のアクティビティを一元的に監査・監視したい場合に適しています。

比較マトリクス

特徴	CloudTrail証跡	組織の証跡
範囲	単一アカウント	複数アカウント
作成と管理	各アカウントで個別に設定	管理アカウントが一括設定
コスト	アカウントごとに発生	組織全体で最適化可能
管理の容易さ	アカウントごとに個別管理	一元管理で簡素化
適用シナリオ	単一アカウントの監査・監視	複数アカウントを持つ組織の監査・監視

CloudTrail が自動有効化されるようになった

CloudTrailがすべてのユーザーで自動的に7日間保管され、追跡できるようになりました。

CloudTrail コンソール

クエリできるが、過去90日だけ

CloudTrailの整合性の検証

CloudTrailがhash値を使い、改ざんの検証を行うことができる。

S3のデータ変更の有無の検証に有効

AWS Network Firewall

WAFとの大きな使い所の違いとしては、アウトバウンド。

アウントバウンド通信のIPを制限したい時はこれがおすすめ。

毎週変わるIPからの不正アクセスへのアプローチには向いていない。wafのレートベースが推奨

NACL

以下のコマンドは172.31.16.139からデータが戻ってこないことを指したもの（数値は適当）

2 1234567310 eni-1233a 203.0.113.33 172.31.16.222 0 0 1 4 336 1432917 143291 ACCEPT OK
2 1234567890 eni-12353a 172.31.16.222 203.0.113.33 0 0 1 4 336 1432917 143291 REJECT OK

この場合、戻るときにREJECTされているので、インバウンドは受け入れられて、アウトバウンドがNGなことがわかる。こういう場合はNACLの設定をまず疑う

NACLはNACL単位でインバウンドを許可できる？

できない。ただしセキュリティグループがセキュリティグループAを許可することはできる。

1時ポート

よくあるのが、49152-65535の範囲、この範囲のアウトバウンドをNACLが開けておかないと、クライアントが動的ポートでアクセスしてきた時に対応できなくあんる

120

Custom

TCP

49152-65535

0.0.0.0/0

許可

WAF

CAPTCHA

AWS WAF は、CAPTCHA パズルおよびサイレントチャレンジを使用して、リクエストがボットから配信されたものではないことを確認し、AWS WAF トークンを使用してクライアントで最近成功した応答を追跡します。

count

AWS WAF はリクエストをカウントしますが、リクエストを許可するかブロックするかは決定しません。これは非終了アクションです。AWS WAF がウェブ ACL の残りのルールの処理を継続します。定義したルールでは、リクエストにカスタムヘッダーを挿入し、他のルールで一致するラベルを追加できます。

リソースポリシー

wafはリソースポリシーというものはない

AWS Audit Manager

具体的には、一般データ保護規則 (GDPR)、医療保険の携行と責任に関する法律 (HIPAA)、ペイメントカード業界データセキュリティスタンダード (PCI DSS) といった、進化する複雑な規制やコンプライアンス標準に対応する為に継続的な自動エビデンス収集やエビデンスを基にして監査レポートの作成が可能

Amazon GuardDuty

ユーザの操作や通信などのログを継続的にモニタリング、不審なサーバーとの通信や不正アクセスなど「悪意がある」と疑われる挙動を、機械学習を用いて検出します

複数アカウントの監視

アカウントをリストにいれ、承認を受け入れることで複数アカウントのアラートを中央で検知可能

CloudTrailとの連携

Amazon GuardDuty は、CloudTrail からのログやイベントを利用して侵入検知システム (IDS) として機能します。これにより、セキュリティエンジニアは、IDS の範囲を最大化することができます。また、Amazon EventBridge と Amazon Simple Notification Service (SNS) を使用して、検出イベントを運用チームが使用する電子メール配信グループに通知することができます。

両方ONにしてたら自動で検知するという情報すらある

ThreatPurpose

とは、攻撃型または潜在的な攻撃型の脅威の主な目的についての説明です。GuardDuty 脅威の目的の一覧表については、次のセクションを参照してください。

・影響

この値は、GuardDuty がアクティビティまたはアクティビティパターンを検出することにより、ユーザーのシステムおよびデータを操作、中断、または破壊しようとしていることを示しています。

・検出

この値は、GuardDuty がシステムおよび内部ネットワークに関する知識を拡張するために使用する可能性のあるアクティビティまたはアクティビティパターンを検出したことを示します。

・動作

この値は、GuardDutyは特定の AWS リソースの確立されたベースラインとは異なるアクティビティやアクティビティパターンを検出したことを示します。

自動アーカイブ

特定のユーザーやイベントなど、ログイン試行で通知が不用意に連続される場合は、

特定のユーザー名やイベントを自動アーカイブして通知しなくする設定が可能

以下の3つのサービスの違いAmazon GuardDuty AWS Security Hub AWS Control Tower

内容
AWS Control Tower
- 目的: AWS環境の設定と管理を簡素化するためのサービス。
- 機能:
  - マルチアカウントAWS環境のセットアップとガバナンス。
  - 組織全体のベストプラクティスの適用。
  - セキュリティ、運用、コンプライアンスのガードレール（自動化されたルールとポリシー）の適用。
  - 既存のアカウントや新規アカウントを迅速に作成し、統制された方法で管理。
AWS Security Hub
- 目的: セキュリティアラートとセキュリティ態勢管理を統合するためのサービス。
- 機能:
  - AWS全体からセキュリティ関連のデータを収集、集約し、ダッシュボードで表示。
  - AWSの複数のセキュリティサービス（GuardDuty、Inspector、Macieなど）やパートナー製品からの結果を一元管理。
  - セキュリティ基準（CIS AWS Foundations Benchmarkなど）に対するコンプライアンスチェック。
Amazon GuardDuty
- 目的: 継続的な脅威検出とモニタリングを行うためのサービス。
- 機能:
  - AWSアカウント全体のログデータ（VPC Flow Logs、CloudTrail、DNSログなど）を分析し、異常なアクティビティや潜在的な脅威を検出。
  - マシンラーニングとルールベースの検出を利用して、セキュリティインシデントを自動的に識別。
  - 検出された脅威に関する詳細な情報と推奨アクションを提供。
違いのまとめ
- Control Tower: AWS環境全体のセットアップと管理を簡素化し、ベストプラクティスの適用を自動化する。
- Security Hub: セキュリティ関連データを統合し、セキュリティ態勢の可視化とコンプライアンスチェックを提供する。
- GuardDuty: ログデータを継続的に分析し、脅威検出とセキュリティインシデントのモニタリングを行う。
これらのサービスを組み合わせて使用することで、AWS環境のセキュリティを強化し、管理を効率化することができます。

Amazon Detective

GuardDutyが有効になってから48時間は経過している必要がある

限定された領域の監視に有効、逆にVPC全体などではコストが嵩む懸念がある

Amazon GuardDutyとAmazon Detectiveの違い

Amazon GuardDutyとAmazon Detectiveの違い
Amazon GuardDuty

目的: Amazon GuardDuty は、AWS 環境の継続的な脅威検出サービスです。脅威を検出し、潜在的なセキュリティ問題を特定することを目的としています。

主な機能:
- 脅威検出: GuardDuty は、AWS CloudTrail、VPC Flow Logs、DNS ログなどのデータソースから情報を収集し、機械学習アルゴリズムやサードパーティの脅威インテリジェンスを用いて脅威を検出します。
- 検出結果の通知: 異常な活動や潜在的な脅威が検出されると、アラートを生成します。
- 簡単な設定: GuardDuty は有効化が簡単で、追加のハードウェアやソフトウェアのインストールは不要です。
ユースケース:
- 不正アクセスの検出
- 内部および外部の攻撃の識別
- セキュリティポリシーの違反の発見
Amazon Detective

目的: Amazon Detective は、セキュリティインシデントの詳細な調査と分析を支援するサービスです。既に検出された脅威や異常な活動の根本原因を特定し、詳細なインサイトを提供することを目的としています。

主な機能:
- データの自動収集と分析: Detective は、AWS CloudTrail、Amazon VPC Flow Logs、Amazon GuardDuty の検出結果からデータを自動的に収集し、グラフベースのデータモデリングを使用して相関関係を分析します。
- 調査支援: インシデントのタイムラインや影響範囲を視覚的に表示し、疑わしいアクティビティの詳細な調査をサポートします。
- インサイトの提供: 複雑なインシデントを理解しやすくするための視覚化と分析ツールを提供します。
ユースケース:
- セキュリティインシデントの詳細な分析
- 脅威の根本原因の特定
- 調査プロセスの効率化
主な違い
- 目的: GuardDuty は主に脅威を検出するためのサービスであるのに対し、Detective はその検出結果をさらに詳細に調査し、分析するためのサービスです。
- 機能: GuardDuty は継続的なモニタリングとアラート生成を行い、Detective はインシデントの詳細な調査と因果関係の分析を行います。
- ユースケース: GuardDuty はリアルタイムでの脅威検出とアラート通知に重点を置いており、Detective は検出されたインシデントの深堀りと根本原因の解析に重点を置いています。
両者は連携して使用することで、AWS 環境のセキュリティを強化し、脅威の検出から詳細な調査まで一貫したセキュリティ運用を実現できます

Amazon Inspector

「ECR 基本スキャン」は Amazon Inspector のような詳細な脆弱性分析やセキュリティ評価を提供しない

新しいメンバーアカウントへの自動スキャンが有効

EC2インスタンスの脆弱性を発見するのにも便利

セキュリティグループ

異なるリージョンにあるピア VPC のセキュリティグループを参照することはできない。同じリージョン内のみでしか参照での許可機能は機能しません。

WAF

wafはリソースポリシーをサポートしない

AWS WAF (Web Application Firewall) でウェブACL (Web Access Control List) のログを Kinesis Data Firehose に送信する設定は、AWSコンソール内のAWS WAFの設定から行うことができます。

KMS

AWSマネージドキーはAWS管理のため、手動でのローテーションができない

AWSマネージドキーは毎年ローテーションされる

デフォルトのAWSマネージドキーは自動ローテーションができない

KMS データキーキャッシュを使用すると、データキーを再利用し、KMS 呼び出しを減らし、コストを最適化できる

AWS Key Management Service (AWS KMS) のカスタマーマネージドキーが「Disabled」に設定されている場合、そのキーは暗号化または復号化の操作に使用できません。

grant

aws kms create-grantで取得可能。

一時的な権限を与える仕組み

kms:CreateGrant権限が対応

4KB以上のデータを暗号化、複合化するとき

はkms:GenerateDataKey または kms:Encrypt アクションに対して GrantTokens を要求する必要がある

エンベロープ暗号化

キーを暗号化し、それをさらに暗号化する2重暗号化の仕組み

ちょっと難解なので後日もうちょい調査

暗号化コンテキスト

キーと値の例

  "Condition": {
      "StringEquals": {
            "**kms:EncryptionContext:AppName**": "ExampleApp",
            "**kms:EncryptionContext:Version**": "1.0.24"
            
} } }

AWS Database Encryption SDKを用いて、DynamoDBのデータを暗号化できますか？

はいできます、以下がコード例

import boto3
import aws_encryption_sdk
from aws_encryption_sdk import CommitmentPolicy
from aws_encryption_sdk.keyrings.aws_kms import AwsKmsKeyring

# AWS KMSのCMKのARNを設定
key_arn = 'arn:aws:kms:your-region:your-account-id:key/your-key-id'

# DynamoDBクライアントの作成
dynamodb = boto3.client('dynamodb', region_name='your-region')

# AWS KMS Keyringの作成
keyring = AwsKmsKeyring(generator_key_id=key_arn)

# 暗号化するデータ
data_to_encrypt = {
    'id': {'S': '123'},
    'name': {'S': 'John Doe'},
    'email': {'S': 'john.doe@example.com'}
}

# AWS Encryption SDKの暗号化
encrypted_data = {}
for key, value in data_to_encrypt.items():
    plaintext = value['S'].encode('utf-8')
    ciphertext, _ = aws_encryption_sdk.encrypt(source=plaintext, keyring=keyring)
    encrypted_data[key] = {'B': ciphertext}

# 暗号化されたデータをDynamoDBに保存
dynamodb.put_item(
    TableName='your-dynamodb-table',
    Item=encrypted_data
)

DynamoDBのコンソールから見ると暗号化された形で保存されています。

ただし、DynamoDB 暗号化クライアントを使うのが、dynamoDBに関しては一番手軽

尚且つ不正なデータ変更も検出できる

キーポリシー

キーポリシー例

{
    "Version": "2012-10-17",
    "Id": "key-default-1",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        }
    ]
}

キーストアとキーマテリアルのマトリクスに関して、メリデリ整理

キーストアとキーマテリアルのマトリクス

特徴	デフォルトキーストア	カスタムキーストア	キーマテリアルの有無
セットアップの容易さ	簡単にセットアップ可能	設定が複雑になることが多い	キーマテリアルの有無に関わらずセットアップが必要
運用管理	管理が簡単	管理が複雑	キーマテリアルの生成と管理が必要
セキュリティ	標準的なセキュリティ	高度なセキュリティ設定が可能	キーマテリアルがある場合、より高いセキュリティ
コスト	コストが低い	カスタムソリューションのためコストが高いことが多い	キーマテリアルの生成と管理にコストがかかることがある
スケーラビリティ	スケーラブル	設計次第でスケーラブル	キーマテリアルの管理次第
カスタマイズ性	制限される	高いカスタマイズ性	キーマテリアルがある場合、柔軟にカスタマイズ可能
互換性	一般的に高い	他システムとの互換性は設計次第	キーマテリアルのフォーマットに依存

カスタムキーストアを使う場合はCloudHSMが必要となる。

デフォルトのキーストアでもカスタマーキーのインポートは可能

また、キーの自動失効期間の設定を行うときは、自分でキーマテリアルをインポートしカスタマーマネージドキーを作ることで実現可能

KMSのラッピングキー　インポートトークン　キーマテリアルの関係性

内容
- ラッピングキー (Wrapping Key): ユーザーのキーマテリアルを暗号化するために使用される一時的な公開鍵。AWS KMSが提供します。
- インポートトークン (Import Token): キーマテリアルが正しいCMKに関連付けられていることを確認するためのトークン。AWS KMSが提供します。
- キーマテリアル (Key Material): ユーザーが独自に生成した暗号鍵データで、CMKにインポートされます。

KMSにおいてカスタムキーストアを使用するメリット

カスタムキーストアを使用すると、HSM（ハードウェアセキュリティモジュール）を使用して暗号鍵を管理できます。

Encryption Context

ざっくりいうと完全な暗号化

対象鍵暗号化単体では気付けないデータの改竄を防ぐ仕組み

AADに対応

一時的なキーの使用

Grantを作成することで実現可能

AWSのポリシーのbool if exists とboolの違い

Bool は、キーが存在しない場合、条件は false となりアクセスは拒否されます。
BoolIfExists は、キーが存在しない場合、条件は無視され、デフォルトのアクセス許可または拒否の設定に従います。

BoolIfExistsを使用したい場面

もしキー自体がなくてもDenyしたい場合に使う

例えばaws:MultiFactorAuthPresentをマストにしたい場合、

boolでdenyだとMultiFactorAuthPresentのconditionが存在しない場合にdenyに行かない。

なのでBoolIfExistsである必要がある。

キーが存在しなくてもtrueを返せるのがいいところ。

Systems Manager パラメータストアのsecure stringとSecret Managerのパラメータでのメリットデメリット

内容詳細

AWS Systems Manager Parameter Store

概要:

パラメータの管理およびストレージサービス。
パラメータの種類としてプレインテキスト文字列、Secure String（暗号化された文字列）をサポート。
シークレットをKMS（Key Management Service）で暗号化。
IAMポリシーを使ってアクセス制御を管理。

メリット:

コスト: 基本的に無料で、Secure Stringの場合も少量のコストで利用可能。
統合: SSMエージェントを利用することで、EC2インスタンスやオンプレミスのサーバーとの統合が簡単。
バージョン管理: パラメータのバージョン管理が可能。
アクセス制御: IAMポリシーを使って柔軟にアクセス権を設定できる。

デメリット:

ローテーション: 自動ローテーション機能がなく、手動で行う必要がある。
シークレットの管理: 大量のシークレットや複雑なシークレット管理には向かない。

AWS Secrets Manager

概要:

データベース認証情報、APIキー、その他のシークレット情報を安全に保存および管理するサービス。
シークレットの自動ローテーション機能があり、AWS Lambdaを利用してカスタムローテーションも可能。
デフォルトでKMSを使用してシークレットを暗号化。

メリット:

自動ローテーション: シークレットの自動ローテーションが可能で、セキュリティを高める。
管理の簡素化: シークレットの管理が容易で、APIやコンソールから簡単にアクセスできる。
通知機能: シークレットのローテーション時にSNSなどで通知が可能。

デメリット:

コスト: 使用量に応じて追加コストが発生する。特に大規模なシークレット管理の場合にはコストが高くなる可能性がある。
複雑性: 使い方が若干複雑で、特にカスタムローテーションの設定には技術的な知識が必要。

比較

特徴	Parameter Store	Secrets Manager
コスト	基本無料（Secure Stringは少量のコスト）	使用量に応じて追加コストが発生
ローテーション	手動	自動ローテーション機能がある
バージョン管理	あり	あり
暗号化	KMSを使用	KMSを使用
アクセス制御	IAMポリシーで管理	IAMポリシーで管理
管理の容易さ	シンプルなシークレット管理向け	複雑なシークレットや大量のシークレット管理に適している

まとめ

単純なシークレット管理やコスト重視の場合は、AWS Systems Manager Parameter Storeが適しています。
自動ローテーションや高度なシークレット管理が必要な場合は、AWS Secrets Managerが適しています。

選択は、具体的なユースケースや必要な機能、予算に基づいて行うと良いでしょう。

Systems Manager でアクセスするには以下のような権限が必要

権限詳細

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:UpdateInstanceInformation",
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "key-name"
        }
    ]
}

–pending-window-in-daysオプション

7日〜30日の削除保留期間を指定できる

キーの共有

デフォルトのマネージドキーは他アカウントと共有できないので、作成する必要がある

（暗号化したRDSのスナップショットを他アカウントと共有する時などに使用）

Security Hub

Security Hubを使用するにはconfigが有効になっている必要がある。

Config とGuard dutyの違い

AWS ConfigとAmazon GuardDutyは、どちらもセキュリティとコンプライアンスを支援するためのAWSサービスですが、目的と機能が異なります。以下に両者の違いを説明します。

AWS Config

目的

AWS Configは、AWSリソースの設定を追跡、評価、監査、および記録するためのサービスです。リソースの設定履歴を保持し、設定の変更を追跡することができます。

主な機能

設定変更の追跡: AWSリソース（例：EC2、S3、IAMなど）の設定変更を継続的に監視し、その履歴を記録します。
コンプライアンス評価: 設定ルールを定義し、リソースがこれらのルールに準拠しているかどうかを評価します。
設定のスナップショット: 任意の時点でリソースの設定状態をスナップショットとして取得し、保存します。
リソース関係の可視化: リソース間の依存関係や関係を視覚的に表示します。

使用例

セキュリティポリシーやベストプラクティスに対するリソースのコンプライアンスチェック
変更履歴の監査
設定変更の通知やアラート

Amazon GuardDuty

目的

Amazon GuardDutyは、AWSアカウントやワークロードのための脅威検出サービスです。リアルタイムで悪意のある活動や不正行為を検出します。

主な機能

脅威インテリジェンス: 既知の悪意のあるIPアドレスやドメイン、攻撃パターンを利用して脅威を検出します。
機械学習: 異常な行動やパターンを検出するために機械学習アルゴリズムを使用します。
クラウドTrail、VPCフローログ、DNSログの分析: これらのログを分析し、異常や潜在的な脅威を特定します。
アラート: 検出された脅威に対するアラートを生成し、対応を促します。

使用例

不正アクセスやアカウントの乗っ取りの検出
マルウェアやデータ侵害の監視
ネットワークトラフィックの異常検出

比較まとめ

特徴	AWS Config	Amazon GuardDuty
主な目的	リソースの設定変更とコンプライアンスの監視	脅威の検出とセキュリティの監視
監視対象	AWSリソースの設定	AWSアカウントやワークロードの脅威
主な機能	設定履歴、コンプライアンス評価、設定のスナップショット	脅威インテリジェンス、機械学習、ログ分析
使用例	リソース設定の監査、コンプライアンスチェック	不正アクセス検出、マルウェア監視

これらのサービスは、相互補完的に使用することで、セキュリティとコンプライアンスの両面でより強力なAWS環境を構築することができます。

CloudWatch

エージェントを入れることで、CloudWatch Logsにログを蓄積できる

詳細なCloudWatch のメトリクス

Amazon CloudWatch のメトリクスはモニタリングに特化しており、API のアクセスパターンを分析できない

CloudWatch エージェントとSSMエージェントをEC2に入れた場合の違い

CloudWatch エージェントとSSM エージェントは、両方とも AWS の管理と監視を支援するためのツールですが、それぞれ異なる目的と機能を持っています。以下にその違いを説明します。

CloudWatch エージェント

目的: 主にメトリクスとログの収集および送信を担当します。

機能:

メトリクスの収集: CPU、メモリ、ディスク使用率、ネットワーク統計などのシステムパフォーマンスデータを収集します。
ログの収集: アプリケーションログ、システムログ、カスタムログファイルを収集し、CloudWatch Logs に送信します。
カスタマイズ可能: JSON 設定ファイルを使用して、収集するメトリクスやログの設定を詳細にカスタマイズできます。

使用例:

サーバーやアプリケーションのパフォーマンス監視
ログの集中管理と分析

SSM エージェント

目的: EC2 インスタンスおよびオンプレミスサーバーの管理を簡素化するためのエージェントです。

機能:

Run Command: インスタンスに対してコマンドをリモートで実行します。
パッチ管理: パッチ適用を自動化し、インスタンスのセキュリティとコンプライアンスを維持します。
Session Manager: シェルアクセスを提供し、SSH や RDP の代替として使用できます。
Inventory: インスタンスのソフトウェアや構成情報を収集し、インベントリとして管理します。
State Manager: インスタンスの設定を自動的に適用および維持します。

使用例:

インスタンスのリモート管理と操作
インスタンスのセキュリティパッチの適用
システム構成の管理と維持

まとめ

CloudWatch エージェントは主にモニタリングとログ管理に特化しています。
SSM エージェントはリモート管理、パッチ適用、構成管理などの幅広い管理機能を提供します。

CloudWatch Logs Insights

クラウドウォッチの情報をクエリして、中身を検索できるサービス

ちなみにAPIゲートウェイからs3へのログ出力機能は基本サポートされていない

メトリクスはAPIの使用状況の分析には向いていない

AWS Audit Manager

Audit Managerでは、CISベンチマークを初めとした様々なセキュリティ規格をフレームワークで管理し継続的に監視することができます。

CloudHSM

CloudHSMマネジメントコンソールの呼び出し、CloudHSM API呼び出しはCloudTrailに記録される

AWS Config

IAMのキーローテーションの期間超過を検出可能

自動検出オプションを用いて、SystemManagerのランブックを起動可能

リアルタイムのアラートにはマッチしていないので、そういう時はCloudTrailからCloudWatch Logsのメトリクスフィルターなどを介して実施するのがよい

非準拠の構成

に対応する場合は、Systems　Manager Automationなどをconfigと併用し使用するのが良い。

Proactiveモード

re:Invent2022でAWS Config Ruleに新しい評価モードとして「Proactive」モードが追加されました。これまではConfig Ruleに非準拠のAWSリソースが作成、設定変更後にCofigによるコンプライアンスチェックが実施されていましたが、この新しい評価モードにより事前にチェックすることができるようになりました。

AWS Config 適合パック (Conformance Packs)

組織の求めるconfigのルールをorganization配下のアカウントに適合できる仕組み

Config Aggregator

各アカウントからconfigの設定を吸い取るシステム

ログ自体ではなく設定のみ。

AWS Config Rules

以下のような形でlambdaを実装してカスタムルールを作れる

def evaluate_compliance(configuration_item):

KMS クライアントの作成

kms_client = boto3.client(‘kms’)

DevOps関連

Elastic Beanstalk

s3とアクセスできない時気にすること：

インスタンスプロファイルがIAMロールに紐づいているか。

AWS CloudFormation

CloudFormation Guard

これを使うと、CloudFormation のYAMLテンプレートにコンプライアンス違反やセキュリティ上の設定ミスがないかデプロイ前にチェックできる

変更セットとstackセットの違い

変更セット (Change Sets)

目的:
- 変更セットは、CloudFormationスタックに対する変更を適用する前にプレビューするための機能

スタックセット (Stack Sets)

目的:
- スタックセットは、複数のAWSアカウントやリージョンにわたってスタックを作成、更新、削除するための機能

複数のアカウントやリージョンに一貫したスタックを展開することができます

AWS Service Catalog

AWS Service Catalogは組織としてのガバナンスが適用された製品を、AWS利用者であるユーザー部門が早く簡単に立ち上げる事ができるサービスです。

スタンプを押すように統一的な環境を作成する事が出来る

serviceカタログに対し、ユーザーやポリシーを指定しアクセス許可を出す

Service Catalogにおける制約とは

Service Catalogにおける制約とは、設定した製品単位に適用されるルール

起動制約

起動制約はエンドユーザーが製品を起動する時に、どのIAMロールの権限を利用して起動するのかを指定する制約です。もっと具体的に言えば、「製品を起動する時にService Catalogが引き受けるIAMロールの指定」となります。

エンドユーザーの権限に許可を与えたくないが、製品を起動させたいケースで活躍する制約です。

CloudFormation 動的な参照

Secrets Manager などからDBのアクセスパスワードを取得する際などに使用。

DB関連

DynamoDB

https通信のみサポートしている

RDS

RDSを暗号化するには

スナップショットをコピープロセスの暗号化で暗号化する。

新しい暗号化キーを作成し、それを操作用の暗号化キーとして使用する。

CloudFront

カスタムドメインで認証および承認されたユーザーにコンテンツを安全に提供する手段として、CloudFront 署名付き URL を使用できる

SecurityHeadersPolicy マネージドレスポンスヘッダーポリシーは、AWS CloudFront を使用して中間者攻撃からウェブサイトを保護するセキュリティヘッダーをレスポンスに追加する機能がある

AWS CloudFrontのIP範囲

jsonで公開されており、定期的に更新される。これを取得するプログラムを設定するなどはある程度一般的

CloudFrontのOAIの制限

CloudFrontのOAIはKMSとの併用はできないので、lambda@edgeなどで暗号化のフォローをする必要がある

Lambda@edge でオリジンレスポンスのタイミングカスタムヘッダーをつけれる？

つけれる

ECR

ECRのリポジトリポリシーの例

特定のIAMロールに対する読み取り専用アクセスの許可:

jsonコードをコピーする
{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/ECRReadOnlyRole"
      },
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ]
    }
  ]
}

その他

Elastic Load Balancer

Elastic Load Balancer のアクセスログはS3 バケットにしかストリーミングされない

Application Load Balancer

ALBの優位性

具体的には、Network Load Balancer (NLB) は主に Layer 4(トランスポート層) の負荷分散に特化しています。SSL/TLS のターミネーションのような Layer 7(アプリケーション層) の高度な機能が求められる場合、Application Load Balancer (ALB) の使用が推奨されます。

APIゲートウェイ

REGIONAL

PRIVATE

がある。

PRIVATEは特定のVPCからのアクセスのみ許容する形となる。

単語関連

サーバーサイドリクエストフォージェリ (SSRF) 攻撃

サーバーが行うリクエストを攻撃者が偽造する攻撃です。簡単に話すと攻撃者が脆弱性があるサーバーを利用して内部のサーバーに攻撃リクエストを送る攻撃

インスタンスメタデータサービス (IMDSv2) のバージョン 2

IMDS v2を利用してメタデータを取得するためにはPUTメソッドで発給してもらったTOKENが必要になるので攻撃の難易度が高くなり、より強化されたセキュリティを構成できます。

以下条件でもv2の制御、判別可能。

これのよさはすでに稼働中のEC2インスタンスに対してでもこの条件で判別されていること

numericLessThan

ec2:RoleDelivery:2.0

インスタンスメタデータは、ホスト名、イベント、およびセキュリティグループなどでカテゴリ分けされます。

AWS Glue DataBrew

databrew とquicksightの違い

AWS Glue DataBrewとAmazon QuickSightは、データの準備と可視化のために使用されるツール

単純にDataBrewはデータの変換、整形ツールなので、まったく違う

リフトアンドシフト

は、クラウド環境への移行戦略の１つです。

リフトアンドシフトでは、第１段階としてクラウドへ既存のアプリケーションをそのまま移行しつつ、第２段階でアプリケーションをクラウドへ最適化していきます。

EKS

Amazon Elastic Kubernetes Service (Amazon EKS) クラスターのコントロールプレーンログは、デフォルトでは Amazon CloudWatch Logs に送信されません。ログを CloudWatch Logs に送信するには、Kubernetes API サーバーコンポーネントログを各クラスターで個別に有効にする必要があります。この設定により、CloudTrail の制約にかかわらず、Kubernetes のイベントを CloudWatch で効果的に監視することができます。

Well Architected Tool

カスタムレンズ

以下のような定義ファイル設定を行うことで、コストやセキュリティを含めた監査を実行してくれる


- pillars[] # 柱
  - questions[] # 質問
    - choices[] # ベストプラクティス(チェック項目)
        - 内容
        - helpfulResource # 画面右端に出す「便利なリソース」欄
        - improvementPlan # リスクありと判断した場合に画面下に出す「改善計画」欄
        ....
    - riskRules[] リスク判定条件
        - 条件(choicesのidで条件を記述) & リスク

Route 53

位置的情報ルーティングはアクセスを拒否できるか？

→あくまで位置は優先づけなので、拒否はできない、おすすめはCloudFrontで制限する形

サブドメインへのDNSSEC登録時

親ドメインへのDerigation signer登録が必要

フォレンジックとは

フォレンジックは法科学の一種で、事故・事件の痕跡や証拠を調査して原因究明を行うことを指します。調査の対象（事故現場）がコンピュータなどの場合、デジタル・フォレンジックと呼ぶ方が正しいのですが省略されることもしばしばあります。デジタル・フォレンジックでは主にコンピュータ、ネットワークなどのセキュリティ事故（インシデント）や内部不正行為などを調査解析して事故原因や裁判で取り扱う証拠の特定などを行います。分かりにくいので、ピンとこない場合は名探偵コナンにでてくる鑑識のトメさんみたいなイメージをもっていただければと思います。

フォレンジックIPアドレスからのアクセスを許可する理由

攻撃者の活動監視:
- 犯罪者の活動を監視し、攻撃の手法やパターンを理解するために、攻撃者が利用するIPアドレスからのアクセスをあえて許可します。
- これにより、攻撃者の行動を追跡し、詳細な調査や分析を行うことができます。

AWS IoT

wirelessDataAccess

IoTWirelessとの接続の権限

Amazon OpenSearch Service

フルテキスト検索、構造化データの検索、ネストされたオブジェクトの検索

が可能だが、例えば特定のIAMアクセスキーのログを検索する時などはAthenaの方が良い

スクリプトクエリなどもいるが、ちょっと調整が必要。

アカウント（属性タグ）ベースのアクセス制御

問２の解説を書く

Trusted Advisor

推奨されるリソースの提案を行うサービス

対話型セッション

コマンドラインなどのようなコマンド上での操作セッションのこと

ブレークグラスユーザー

緊急アクセス用管理者アカウント(Break Glass アカウント) とは、普段利用している管理者アカウントが利用できなくなった時など緊急時に使用する管理者アカウント

RDS

DB暗号化

暗号化したDBを作るためにはスナップショットを用いて、スナップショットの暗号化実施を行う必要がある。

スナップショットから暗号化したスナップショットをコピーする形となる。

追記

AWS Control Tower と Security Hub と GuardDuty の違い

AWS Control Tower

ユースケース：

ログの一元管理を行い、cloudtrailで情報を1アカウントに集積する。
ルールに準拠していないリソースやアカウントを一覧できるダッシュボードの提供

利用可能なすべてのリージョンで CloudTrail を有効にし、それを防止するガードレール設定が可能

S3 バケットへのパブリック読み取りアクセスを不許可にする行為の検出が可能