[備忘録]SCS試験対策


SCS試験勉強のため、学んだことをメモしていく

## メモ
- Trusted Advisorのレポート結果をトリガーにしてlambda処理を実行するには、CloudEventを橋渡しとする。Trusted Advisorでlambdaの高頻度エラーの関数などチェックできるが、Trusted Advisorをトリガーとして処理することはできない。
![スクリーンショット 2022-12-03 9.22.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2841868/9d42fea4-43d5-555e-9ca9-053b20ef43ac.png)

- S3バケット項目の`sid`はポリシー識別番号
- パラメータストアとSecretsManagerの違い
自動ローテーション、有料 → SecretsManager
無料　→ パラメーターストア
※監査・監視は両方可能

こちらが分かりやすかった
[AWSのParameter StoreとSecrets Manager、結局どちらを使えばいいのか？比較 \- Qiita](https://qiita.com/tomoya_oka/items/a3dd44879eea0d1e3ef5)

- CloudTrailのログイベントは３種類
    - 管理イベント　：IAMユーザーのAWSリソースに対する管理オペレーションを記録
    - データイベント ：実行されたAWSリソースのAPIオペレーションを記録
    - insightイベント　：AWSリソースで実行された異常な書き込みオペレーションを記録

- メモリダンプ ：その瞬間にメモリ上に展開されているプログラムやデータを１つのファイルとして保存する。EC2では、診断割り込み（NMI）の中でダンプすることも可能だが、使用できるインスタンスタイプが限られている。
- NACLでHTTP通信を許可するとき、アウトバウンドトラフィックにはクライアントがサーバーに接続するためのポート番号（OSによって異なる）を許可する必要がある。1024~65535まで許可する。
- SESはTLS標準に準拠するポート587を使用することを推奨している。TLSで暗号化された接続を確立するために、STARTTLSとTLSラッパーをサポートしている
- KMSは４キロバイトまでの文を暗号化する
- EFSは新規作成時に保管時の暗号化、EC2へのマウント設定時に転送時の暗号化を設定できる
- S3でHTTPセキュリティヘッダを使いたい場合、CloudFront＋Lambda@edge（AWS管理の設計図あり）で実装
- RedShiftの暗号化は、クラスター（リーダーノード＆コンピューターノードの塊）の新規作成時に設定できる。すでにある場合はデータを移す必要がある。暗号化はKMSが使われ、大量のデータを暗号化するためにキーが階層になっている。カスタマーのキーは使用できない。
- CloudTrailのアカウントアクティビティはリアルタイムではなく、15分以内にログ配信する
- CloudTrailのアカウントアクティビティログは90日間保管される。それ以降はS3にデータコピーをすればログを確認できる。
- AutoScalingの場合、IPアドレスを使用したセキュリティグループの設定ができないため、セキュリティグループを関連づける
- ELBでHTTPSリスナーを使用している場合、選択するセキュリティポリシーで暗号と暗号プロトコルが決まる。なので、暗号と暗号プロトコルの脆弱性が見つかった場合、セキュリティポリシーを変更する。
- KMSのマスタキーとデータキーの違い
 https://dev.classmethod.jp/articles/10minutes-kms/
- インスタンスメタデータサービス（インスタンス情報を表示）では、EC2に割り当てられた権限が一時利用できるアクセスキーを発行する機能もあり悪用される可能性がある。これを受け、v2ではセッショントークンを事前に取得する必要があったり、v1v2の両方を無効化できるようになった。
- CloudFrontで閲覧者制限のあるS3を配信する際は以下の手段が考えられる
    - CloudFrontで署名つきURLを発行する。S3はCloudFront経由のアクセスに制限するため、OAを設定する。(署名を発行するIAMユーザーを信頼された署名者という）
    - Cognitoと連携すると認証済みの特定ユーザーのみが閲覧できる。（認証済みかどうかは、Lambda@edgeをCognitoの前段に置いて、確認する仕組みが良い）
- ACMはリージョナルリソースなので、リソースがリージョンを跨いでいる場合それぞれ必要になる。リージョン間コピーはできない。 
- EC2のCloudWatchログをリアルタイムに取得するには、CloudWatchエージェント→CloudWatchLogs→Kinesis Firehose→S3の順にデータを送信する
- リアルタイムにデータ処理・送信はkinesisシリーズの可能性が高そう
- AWS Shieldはレイヤー3.4を保護するので、Route53やCloudFrontと連携するのがベスト
    （スタンダードが3.4のみ、アドバンスドは3.4.7を検知）
- IAMでダウンロードできる認証情報レポートで、アカウントのポリシーや最終アクセスなど確認ができる
- ルートユーザーのリソース制限ができるのはSCPのみ
- AWS ES（elastic stack）からKibanaへのアクセス制限をかけるには、Cognitoかプロキシサーバーを間に当てる
- S3のアクセス制御は、IAMポリシー、バケットポリシー、S3のACLの3つ
- S3のクライアント側暗号化はコンソールとCLIからオブジェクトにアクセスできない。SDKはサポートされている。
- DirectCnnectはインターネットを介さず、高速で通信できる。暗号化はできないため、早く暗号化させた通信をしたいときはVPNを併用する。VPN単体ではインターネットを経由する必要がある。
-  NLB、プライベート、安全、スケーラブルに子会社などからアクセスときたら「PrivateLink」
- WAFのレートベースで5分間に指定回数以上にアクセスのあったIPアドレスを拒否できる
- KMSはポリシーとGrant（許可・権限）の2つのアクセス許可ができる。グラントは一時的に他のサービスにKMSを利用させたい時に使用する。自動的に許可は削除されないので、削除のオペレーションが必ず必要。適用されているかはCLIで付与されている権限を表示することで確認できる。
- KMSで削除期間決めて削除できるのはインポートをするカスタマー管理CMKのみ（https://zenn.dev/jimon/scraps/cd5f42397dc697）
- SessionManagerを使用するときはセキュリティグループでポート22を拒否する。
- SessionManagerでCloudWatchLogにSSH操作を記録することができる
- アクセス権限の境界（IAM Permissions boundary）は、Permissions policy でどんなに強い権限が与えられていたとしても、Permissions boundary によって設定された境界を超えたアクションは実行できないこと
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2841868/8bf52010-ab1e-4307-8f58-578d6f3bf3e4.png)
- 暗号化したEBSのスナップショットを他アカウントと共有するにはカスタマー管理キーの必要がある
- GuardDutyの検知項目（https://blog.serverworks.co.jp/guardduty-ec2-detection-type#GuardDuty%E3%81%A8%E3%81%AF）
- IAMにはパスワードに関するポリシーはない
- DynamoDBの暗号化クライアントは、クライアント側の暗号化、項目に署名を行い、転送・保存中の暗号化を保証する
-  Security HubはGuard DutyやInspectorなどのセキュリティ系のリソースからのデータを一元化できる。Organizationsとも統合しているので複数のAWSアカウントの情報が収集できる。CloudWatch Eventでアクションを起こすことも可能
-  GuardDutyを停止する際は、関連づけているデータソースの無効化とメンバーアカウントの解除・削除を行う

- CMKの手動ローテーションは、新しいCMKをインポートしたあとにKMSキーに新しいCMKのエンドポイントを書き換える必要がある
- AWS inspectorは脆弱性スキャンの他にもセキュリティのベスプラや使用プロトコルなど評価してくれる
- SSMパラメーターストアでSecureStringを使用するときはKMSが使われる。
復号イメージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2841868/cddefa0e-457e-e050-3b96-47787849b8e9.png)