記事の目的
意外とややこしく奥深いAWS Certified Security – Specialty試験対策の中で
AWS若干ワカル自分も新しく知ったことを記載しました。
知らない範囲がどこかの炙り出し程度にご活用ください
記事の対象者
SAAに受かったぐらいの人
SCSを受けたいと思っている人
1-5年AWSに触れている人
注意
chatGPTと共にガーッと書いた記事なので、
記載が少し古くなっていたり、単語の間違いがあるかもですが、
そちらはご愛嬌で。
あくまで知らない、弱い範囲のざっくりとした炙り出し程度にご活用ください
程よくマニアックなことが書かれていることがこの記事の良いところだと思います
見出し
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にマップします。
- Send LDAP Attributes as Claims：LDAP属性をSAMLアサーションとして送信します。
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関連
<
h3>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 バケットへのパブリック読み取りアクセスを不許可にする行為の検出が可能
Security Hub
概要：
複数のAWSセキュリティサービス（GuardDuty、Inspector、Macieなど）およびサードパーティのセキュリティツールからのセキュリティアラートとコンプライアンスステータスを統合し、一元的なダッシュボードで提供
複数のAWSアカウントの一元管理も可能
ベストプラクティスやスコアの表示も可能
GuardDuty
自動で検出を行なってくれるサービス
例えば以下の検出が可能
- 不審なサーバー、IPアドレスとの通信を検出
- EC2インスタンスがDoS攻撃の実行に利用されている可能性を検出
- 悪意ある既知のIPアドレスからのAPI呼び出しを検出
