3. アカウント管理的セキュリティ
対象サービス
- AWS Audit Manager
- AWS CloudTrail
- AWS Config
- AWS Trusted Advisor
- Amazon Detective
- AWS Security Hub
- Amazon GuardDuty
- Amazon Inspector
- AWS IAM
- AWS Directory Service
- AWS Single Sign-On
- IAM Identity Center
- Amazon Cognito*
*試験ガイド内の"AWSのサービスと機能"には記載なし
AWS Audit Manager
フレームワーク(PCI DSSなど)ベースでコンプライアンスチェックを行いS3にレポートを出力する
監査対象サービスを指定して検査することで24時間後に準拠有無とそのエビデンスを確認可能
AWS CloudTrail
ポイント
リージョナルサービス（一括有効化オプション有）
※S3バケットの管理と併せて要チェック
すべてのAPIイベントを保存（期間について要注意）
※デフォルトでは、CloudTrail によって S3 バケットに配信されるログファイルは、Amazon S3 マネージド暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用して暗号化されます
Organizations連携
ログ保護
- “WriteOnceReadMany”(WORM)モデル
- 整合性検証機能（CLIでハッシュを使って同一のものであることを検証）
- S3側の保護
CloudTrail Lake
イベントに対してSQLベースのクエリを実行
CloudTrail Insights
ベースラインを作成して以上パターンの検知
AWS Config
・コンプライアンスチェックと修復（Config, Automation）
・ルールベースでのコンプライアンスチェック
・リージョナルサービス
→Configアグリゲータを使用することで複数アカウントおよび複数リージョンのデータを表示可能
・IAMアクセス許可の変更履歴チェック
マルチアカウントでの構成
Organization配下で複数のアカウントに対してConfigおよびカスタムルールを有効化し、情報を集約する
親アカウントからConfigを有効化し、アグリゲータを作成
※この際にロールや対象リージョンを選択
その後任意のルールをStackSetsで展開する
AWS Trusted Advisor
SGの不必要ポートの検出が出来る
AWS Security Hub
Config, SecurityHub の自動検出および評価方法（検出評価、プロアクティブ評価）
マルチアカウント
通知
修復
Amazon GuardDuty
悪意のあるIPアドレス、異常検出、機械学習などの統合脅威インテリジェンスを使用して脅威を検出（外部からの脅威を検出する）
情報ソースとしては以下
- VPC flow logs
- DNS Logs
- CloudTrail Events
通知
EventBridgeからSNS経由で通知を行う
検出抑制
過検知や誤検出が行われる場合、抑制ルールを使用することが可能
→条件(フィルター)に一致した新規検出を自動でアーカイブすることで検出を抑制する
信頼できるIPリスト/脅威リスト
ホワイトリスト/ブラックリスト形式でのIP除外(VPCフローログに影響を与える)
統合
Amazon Detective：検知内容の相関分析が可能
Security Hub：検出結果の連携
Organization：マルチアカウント展開
保護プラン
- S3 Protection (S3バケットへのデータアクセスに関する保護: https://dev.classmethod.jp/articles/guardduty-threat-detection-coverage-to-s3/)
- EKS Protection (監査ログとランタイムアクティビティ: https://dev.classmethod.jp/articles/guardduty-for-eks-protection/)
- Malware Protection (EC2/ECSのマルウェアスキャン: https://dev.classmethod.jp/articles/guardduty-support-malware-protection/)
- RDS Protection (RDSへのログインアクティビティ: https://dev.classmethod.jp/articles/amazon-guardduty-rds-protection-aurora-ga/)
- Lambda Protection (Lambda関数からの不審ネットワークアクティビティ: https://dev.classmethod.jp/articles/update_guardduty_lambda_protection/)
Amazon Inspector
脆弱性の検出を行うサービス
脆弱性修復について → Organizations と連携することでマルチアカウントでの脆弱性スキャンを構成し各アカウントの検出結果の確認ができる
EC2
SSM Agent を使用してスキャンを行う
※コンソール上で有効化するとマネージドインスタンスに対して定期スキャンを実施する
スキャンタイミング
- 新規 EC2 インスタンスを起動するとき
- 既存の EC2 インスタンス (Linux のみ) に新しいソフトウェアをインストールする場合
- Amazon Inspector が新しい共通脆弱性と危険性 (CVE) 項目をデータベースに追加し、その CVE がお客様の EC2 インスタンス (Linux のみ) に関連している場合。
デフォルト6時間ごとに定期スキャンが実行される（カスタマイズ可能）
コンテナ
有効化後30日以内にPushされたイメージをスキャン
その後のスキャンタイミング
- 新しいコンテナーイメージがプッシュされるたびに
- Amazon Inspector が新しい共通脆弱性と危険性 (CVE) 項目をデータベースに追加し、その CVE がそのコンテナイメージに関連する場合 (連続スキャンのみ)
https://docs.aws.amazon.com/ja_jp/inspector/latest/user/scanning-ecr.html
※30日以前のイメージは再Pushが必要
ECR ベーシックスキャン
オープンソースの Clair プロジェクトの共通脆弱性識別子 (CVE) データベースを使用するベーシックスキャンタイプを提供
プッシュ時または手動でのスキャンが実行可能（各イメージは24時間に1回スキャン可能）
→スキャン結果のリストを提供
※スキャンターゲットのリポジトリをフィルター可能
拡張スキャン
Inspectorとの統合
※スキャンターゲットのリポジトリをフィルター可能
結果はInspectorコンソールで確認
スキャンの差分
スキャン対象や、 Security Hub、Organizationとの統合可否に差分がある
※ベーシックスキャンと拡張スキャンの併用はできない
Lambda
依存関係のスキャンでパッケージに含まれる脆弱性を検出
最新ではコードの脆弱性も検出可能
有効後過去90日以内に呼び出しまたは更新された関数をスキャン
それ以降のスキャンタイミング
- Amazon Inspector が既存の Lambda 関数を発見するとすぐ
- 新しい Lambda 関数を Lambda サービスにデプロイするとき
- 既存の Lambda 関数またはそのレイヤーのアプリケーションコードまたは依存関係を更新する場合
- Amazon Inspector が新しい共通脆弱性と危険性 (CVE) 項目をデータベースに追加し、その CVE がお客様の職務に関連している場合は必ず。
Amazon Detective
AWS上の不審アクティビティを検出した後の分析や調査をサポートしてくれるサービス
データソース
- AWS CloudTrail ログ
- Amazon VPC フローログ
- Amazon GuardDuty
対象アカウントを招待することで開始
AWS IAM
AWSサービスの中で何よりも大事なもの
最強に素敵なブログ（いつもありがとうございます）
ベーシックだけど大事な場所
各ステートメントの優先順位
最も一般的なポリシータイプは、アイデンティティベースのポリシーとリソースベースのポリシーです。リソースへのアクセスがリクエストされると、同じアカウント内の少なくとも 1 つの許可について、AWS はポリシーによって付与されたすべてのアクセス許可を評価します。これらのポリシーのいずれかが明示的に拒否された場合、許可は無効になります。
※Principalはリソースベースポリシーでのみ使用可能
評価論理
ガードレール
- Organizations SCP
- Permissions boundary
アイデンティティもしくはリソースで Allow があるけれどもガードレールで Allow がない、という場合には暗黙的な拒否としたい場合に使用する
例：意図せず高い権限を付与された場合などにもその権限を使用されないようにする
特定条件でのアクセス制御
特定リージョン
"aws:RequestedRegion"を利用
特定サービス
"aws:ViaAWSService"
特定 Organization
"aws:PrincipalOrgID" を利用
MFA
MFAの有効化
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
タイムアウト
"NumericGreaterThanIfExists": {
"aws:MultiFactorAuthAge": "3600"
}
※1時間経過したら○○
ユーザー管理
- root ユーザは使用しない（AK/SKの削除）※削除はできない
- 各用途に応じて IAMグループ(IAMポリシー) - IAMユーザ の作成
- IAMロールを使ってSwitchRoleする
- アクセス時にMFAの認証を必須にする
問題発生時
- AK/SK の更新 (rootユーザでも有効な場合含む)
- IAMユーザパスワードの変更
- CloudTrailから実行された事象を確認し対処
https://dev.classmethod.jp/articles/leak-accesskey-what-do-i-do/
Access Analyzer
リソースベースのポリシーを検査し外部から意図しないアクセスが出来るかを検出する
アクセスアドバイザー
アクセス可能なサービスと最終アクセス履歴の表示
認証情報レポート
IAMユーザ、AKの棚卸サービス（コンソールから出力可能）
取得可能なものは以下（一部省略）
- User名
- ユーザのARN
- ユーザの作成日時
- パスワード有無
- パスワードを利用した最終ログイン日時
- パスワードの最終更新日
- MFAデバイスの有無
- アクティブAK有無
- AKの最終更新日
- AKの最終利用日
https://dev.classmethod.jp/articles/inventory-iam-users-and-access-keys-in-iam-report/
AWS Directory Service
３つの選択肢がある
- AWS Managed Microsoft AD
- Simple AD
- AD Connector
AWS Single Sign-On
SSO + SAML ログイン
IAM Identity Center
この手順を使用して、1 AWS つの管理ポリシーを使用する定義済みの権限セット、または最大 10 AWS の管理ポリシーまたは顧客管理ポリシーと 1 つのインラインポリシーを使用するカスタム権限セットを作成します。IAM のサービスクォータコンソールで、最大 10 個のポリシーへの調整をリクエストできます。
Amazon Cognito
API Gateway との認証連携
SSO 関連ワードイメージ
SSO を実装するために使用されるもの
→SAML / OIDC
SAML
- SP にブラウザでアクセス
- IdPにリダイレクト
- IdPがアイデンティティストアにアクセスしユーザ認証を行う
- 認証が完了したらIdPがアサーションを発行
- アサーションを使ってSPにアクセス
SP
ユーザがアクセスしたい場所、IdPにリダイレクトして認証を行わせる
IdP
リダイレクトされてユーザの認証を行う箇所
- okta
- Active Directory Federation Service
アイデンティティストア
認証情報が保存されている箇所
- okta
- Azure AD
- Active Directory
OIDC (OpenID Connect)
※GoogleやFacebookの情報でほかのサイトにログインするやつ
- アクセスしたいサイトにGoogleの情報でログインを選択
- アクセスしたいサイトからGoogleへトークンの発行依頼を行う
- Googleからユーザに認証の要求（権限確認など含む）
- ログイン情報の入力
- Googleからアクセスしたいサイトにトークンを発行
- アクセスしたいサイトにトークンを使用してログインする
OAuth2.0
OIDCの前任者
- ユーザがゲームに対してSNS連携をリクエスト
- ゲームからSNSに対して連携のリクエスト
- SNSからユーザに連携の承認依頼（ゲームに対して渡す権限の確認）
- ユーザが承認をする
- SNSからゲームに対してアクセストークンを発行
- ゲームはアクセストークンを利用してSNSにアクセス
Discussion