Tweet

Pocket

まずはNIST Cyber Security Framework(CSF)とAWS Well-Architected Frameworkを押さえましょう

セキュリティとクラウドの双方を押さえている「AWS認定セキュリティ」の資格は、今どきエンジニアとしての求められるスキルであると考えられます。
しかし、AWSはセキュリティに力を入れていることを明言していることもあり、セキュリティに関しては膨大な範囲の勉強となります。
そのため、まず大枠を掴むことが学習成果の速度を決めると言って過言ではありません。
その大枠としてはNIST CSFとAWS Well-Architected Frameworkの２つを押さえていれば十分です。
NIST CSF は、コア、ティア、プロファイルの3要素の構成となっています。
コア、ティア、プロファイルはそれぞれ以下の通りなので、具体的な対策に当たるコアとサービスの対応を抑えると良いことになります。

コア：5 つのリスク管理機能(識別、防御、検知、対応、復旧)を支援するためのセキュリティ管理策
ティア：組織のサイバーセキュリティ対策状況の成熟度の4段階評価基準
プロファイル：組織のサイバーセキュリティ対策の「AsIs(現在)」と「ToBe(目標)」

AWSのNIST CSFへの準拠はここに記載されています。
NIST CSFコアの5つのリスク管理機能、識別、防御、検知、対応、復旧とAWSのサービスとの対応をまとめると次のようになります。

NIST Cyber Security Framework(CSF)コア・カテゴリとAWSサービスの対応

AWS Well-Architected Framework

5本の柱、「運用の優秀性」「セキュリティ」「可用性」「パフォーマンス効率」「コスト最適化」で構成されます。
AWS 認定セキュリティにおいてはこの内、「セキュリティ」に焦点を当てれば良いことになります。

協力なアイデンティティ基盤の実装

最小権限の原則をIAMポリシーの形で実装し、職権分掌を徹底させ、適切な認証を実行します。
IAMを用いて権限の管理を一元化します。
AWS Security Token Serviceなどを使用し長期的な認証情報への依存を軽減または解消します。

トレーサビリティの実現

利用中の環境に対してリアルタイムで監視、アラート、監査のアクションと変更を行います。さらにシステムにログとメトリクスを統合し自動で応答してアクションします。
具体的にはVPC Flow LogsやELBアクセスログと言ったサービス単位のログの場合、CloudWatch LosまたはS3に保存しメトリックスを設定しCloudWatchに連携します。
一方、CloudTrail(設定履歴)など監査ログは、脅威を検知するCuardDutyと連携し検知を自動化します。

全レイヤーへのセキュリティの適用

各レイヤーで考えられる対策は全て行うという考え方です。

セキュリティのベストプラクティスの自動化

自動化を前提とし、手動による遅延や漏れをなくすことを目指します。

伝送中および保管中のデータの保護

データを機密性別に分類、アクセスコントロール、暗号化、トークン分割し伝送中、保存中の安全を確保します。

データに人の手を入れない

自動化と共通する遅延や漏れの他、手を入れることによる機密性の侵害、ヒーマンエラーによるリスクを低減します。

セキュリティイベントへの備え

インシデント対応のシミュレーションを実施し、可能な限り自動化されたツールを利用し、検出、調査、普及を行うようにします。

インシデント対応

AWS CloudTrail

先立つログがなければ話にならないので必ず有効にしましょう。

出力先のS3とCloudWatch Logsの使い分け

アラーム(Event)を設置したい場合のみCloudWatch Logs、他は費用を抑えるためS3に保存という使い分けが一般的です。

AWS Config

マネージドルール：AWS側で用意したルールであり、AWS Lambda 関数の作成は不要になります。
カスタムルール：カスタム Config ルール用の AWS Lambda 関数の作成が必要になります。

Configルールの自動修復

修復アクションはConfigルールの「修復の管理」にあるSystems Manager Automationドキュメントから選択できる内容が対象です。
独自のAutomationドキュメントを登録することも可能です。

Step1. AWS Configの有効化します
Step2. IAMロールの作成画面にいきAWS ConfigとSSM Automationの紐付けるためIAM Role を作成します
Step3.信頼されたエンティティの選択でAWSサービスを選択して「ユースケースの選択」の一覧から「System Manager」を選択します。
Step4.Systems Manager　Allows SSM to call AWS services on your behalfの方です。
ssm-automation-role-for-
policy: AmazonSSMAutomationRole
信頼関係＞信頼関係の編集＞信頼されたエンティティで「SSM Automation Service Role」 （ssm.amazonaws.com）を選択します。
AWS Configを用いた定期チェックを設定します

Step5.②Attach アクセス権限ポリシーで「ポリシーの作成」を押下します。
Step6.JSONに以下のような設定を記載します。Actionには是正したいアクションに合わせて記載を変更します。
ec2:RevokeSecurityGroupIngress   →0.0.0.0/0などSecurityGroupがSSH,RDPを含むがアクセス可能になっているのを是正する
ssm-automation-role-for-s3-encryption  →S3の全バケットのデフォルト暗号化を自動的に有効化する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ここに是正アクションを記載する",
            "Resource": "*"
        }
    ]
}

今回適当にec2:RevokeSecurityGroupIngressを設定するとEC2が候補に挙がるので選択します。
名前を付けたら「ポリシーの作成」を押下します。
Step7.AWS Configの画面の左ペインからルール（Config Rules）を選択します(集約ビューの方のルールではない)
Step8.「ルールの追加」を押下します。
Step9.restricted-sshを検索して選択します。
トリガータイプは設定変更or定期的が存在します。
Step10.「修復アクションを選択」にて「AWS-DisablePublicAccessForSecurityGroup」を選択し「自動修復」のラジオボタンで「はい」を選択します。
※「自動修復後もリソースがまだ準拠していない場合は、このルールを再試行するように設定できます。修復スクリプトの実行には費用がかかることに注意してください。」の再試行回数は適時調整ください。
Step11.「リソース ID パラメータ」は「GroupId」を選択します。
Step12.パラメータのキー「AutomationAssumeRole」に対する値で先ほど2で作成したロールの「ロール ARN（コピーを活用しましょう）」を設定します。
Step13.内容を確認して「保存」を押下します。自動的に評価が始まります。

時間をおいて画面を更新すると準拠に変わっているはずです。

イベントソースをConfigとしてCloudWatch Events+Lambdaの修正方法も適時用いることが可能です。
・S3バケットがパブリックになった場合、プラベートにするアクションを起こさせる場合
STEP1 AWS Configを使用してAWSバケットへの変更を監視します。
STEP2 AWS Lambda関数を使用してバケットACLを変更します。

AWS System Manager

LinuxやWindowsのサービスを管理するためのサービスです。SSM エージェントをインストールしていれば管理対象になるのでオンプレミスサーバも管理対象に含めることができます。

Session Manager

プライベートなサブネットにある、グローバル IP をもたない EC2 にも踏み台なしでアクセスができるサービスです。鍵を管理しなくて良い点がメリットだと思います。(Security Groupも)
接続に用いられるssm-userというsudoが実行できるOSユーザなのでRun Asで権限を制限すべきである点に注意しましょう。

State Manager

Documentsを参考に予め定義された状態に保つためのサービスです。

Inventory

Configのブラックリスト機能を利用して定義した禁止ソフトウェアのインストールを検知しアクションすることに繋げられます。

Patch Manger

インストールされているソフトウェア・OSの更新情報をチェックし、自動的にパッチを充ていることができるサービスです。
エージェントが入っていればオンプレミスでも対応可能です。
「チェックのみで更新適応までしない」という設定が可能なので様々な要件に対応することに活用できます。

Run Command

複数台のサーバに同時にシングルステップ処理を指示できるサービスです。

Automation

複数台のサーバに同時に「マルチステップ」処理を指示できるサービスです。
手動承認を含めることも可能です。Documentという形式で作成・保存することが可能です。

Maintenance Windows

AutomationのタスクなどCron形式で特定時刻に実行するために利用されます。

Documents

JSONまたはYAMLでRun CommandやAutomationの処理を文書テンプレート化できます。
他のアカウントに共有し、使用することも可能です。

AWS CloudFormation

AWSリソースをテンプレート化(YAML,JSON形式)し、構築の自動化を実現するサービスです。
意図しない更新や作成に対しロールバックする設定を行うことができます。
まず、ロールバックのきっかけとなるCloudWatchアラームを作成します。
次に、CloudFormationロールバック設定のCloudWatchアラームオプションに設定し完了です。
これで実行後にアラームが発動するとロールバックしてくれるようになります。本番環境での事故防止のために設定して置くことをお勧めします。

cfn-nag

テンプレートのセキュリティ上の問題を検知します。

ドリフト検知

テンプレートと実環境との差分(差異)を検知します。
Configルールの「cloudformation-stack-drift-detection-check」を利用し、①修復アクション、②Automationタスクの実行、③通知するなどの利用が考えられます。

cfn-python-lint

テンプレートの構文エラー(スペルミス等)を検知します。

AWS CloudWatch

CloudWatch APIやエージェントを利用することでオンプレミスを含めたサービス全体のデータを自動収集できるサービスです。
メトリクスとはELBのリクエスト受信数など登録された時間ごとのデータの集合体のことです。

CloudWatchアラーム

CloudWatchアラームを用いて設定された閾値に対しSNSと連携して通知、Lambdaと連携してアクションなど自動対応が設定可能です。
閾値を複数回超えた場合、下回った場合などの条件も設定可能です。さらに機械学習を利用した異常値検出を行いアラートを発生させる異常値検出機能があります。
また組み合わせた復号アラームを作ることも可能です。
例えば不正なAWS APIリクエストが多すぎる場合、API呼び出しエラーコードを検索するAmazon CloudWatchメトリックスフィルターを作成し、そのメトリックスのレートに基づいてアラームを実装することで自動セキュリティアラートを生成できます。

CloudWatchイベント

発生源となるイベントソース(Security Hub,GuardDuty,CloudTrail)と処理内容であるターゲット(Lambda,SNS)を指定します。Cronのようなバッチ処理も実行可能です。

Amazon SNS

マネージド型のPub/Sub(Publish-Subscribe)メッセージングサービスです。疎結合でスケールし易いPub/Subメッセージングモデルをベースに様々なサービスからの様々な形式に対応しトピックをやりとりします。
HTTP\HTTPS,Email,Email-Json,SQS,AWS Lambda,SMS,Amazonなどが対応します。

AWS Trusted Advisor

AWSアカウント内のコスト、パフォーマンス、セキュリティ、フォールトレランス、サービス制限の５つの観点※でチェック項目ごとに３段階の評価を表示・通知(1週間に1回※)してくれます。
※ビジネスサポート以上のサポートプランが必要
※リアルタイムに通知が欲しい場合はリージョンをus-east1(バージニア北部)と設定する必要がある点が注意です。(Trusted Advisor,IAMはus-east1)

Amazon Macie

S3上の個人情報(PII),保護対象保健機情報(PHI)、金融情報(クレジットカード関連)、認証情報(Credentials and sercrets)を自動的に発見、分類、通知してくれるサービスです。
CloudWatchイベントに送信されるので、イベントソースにMacie、ターゲットにSNSを指定して自動通知、Lambdaを指定してマスクや暗号化などの自動修復などを行うことも利用例などが考えられます。
読み方は「メイシー」と読むようです。AWS Organizationsにより複数アカウントに対応可能です。

Amazon Macieの設定手順

東京リージョンで利用可能なので設定手順を紹介します。
STEP1.Amazon Macieのサービス画面で[Get started]、[Macieを有効化]を押下するとダッシュボードが表示されます。
STEP2.S3バケットメニューに遷移し、チェック対象のS3バケットを選択し、右上の[ジョブを作成]をクリックします。
STEP3.ワンタイムジョブか、スケジュールされたジョブか選択します。(お試しならワンタイムジョブを選択)
STEP4.カスタムデータ識別子という正規表現を使った機密データを定義を追加できます。(何もなければからのまま次へを押下)
STEP5.ジョブ名を入力して「次へ」を押下します。
STEP6.内容確認して送信で実行されます。「数時間」後[結果を表示]が押せるようになったら完了です。

Amazon GuardDuty

CloudTrail,S3,IAMをインプット情報に不正やセキュリティイベントを検知するサービスです。
有効にしただけではリアルタイムの検知や通知はされません。CloudWatchイベントを利用してイベントソースにGuardDuty、ターゲットにSNSを指定して自動通知、Lambdaを指定してマスクや暗号化などの自動修復などを行う利用が一般的かと考えられます。
全ての不正リクエストを監視できる訳ではなく、例外としてGuardDutyはこれらのDNSリクエストを認識できません。

AWS Security Hub

コンプライアンス（PCI DSSなど）準拠状況やセキュリティ準拠状況の情報を一元統合してくれるサービスです。
毎度お馴染みのCloudWatchイベントを利用してイベントソースにSecurity Hub、ターゲットにSNSを指定して自動通知、Lambdaを指定してマスクや暗号化などの自動修復などを行う利用が一般的かと考えられます。
AWS基礎セキュリティのベストプラクティスのダッシュボードが非常に見やすく重宝します。
一元統合の対象はAmazon GuardDuty,Amazon Inspector,IAM Access Analyzer,Amazon Macie,AWS Firewall Managerです。

AWS Security Hubを利用するには以下のポリシーをアタッチして、Security Hubコンソールにサインイン、「開始方法」→「Enable Security Hub (セキュリティハブの有効化)」で完了です。

{
  "Version": "2012-10-17",
   "Statement": [
      {
          "Effect": "Allow",
          "Action": "securityhub:*",
            "Resource": "*"
      },
      {
            "Effect": "Allow",
          "Action": "iam:CreateServiceLinkedRole",
          "Resource": "*",
          "Condition": {
              "StringLike": {
                    "iam:AWSServiceName": "securityhub.amazonaws.com"
              }
          }
      }
  ]
}

AWS Detective

時系列情報を含んだ形式でインシデント調査・分析するためのサービスです。
GuardDutyの結果画面から連携可能です。

ログと監視

CloudWatch

CloudWatch APIやエージェントを利用することでオンプレミスを含めたサービス全体のデータを自動収集できるサービスです。
メトリクスとはELBのリクエスト受信数など登録された時間ごとのデータの集合体のことです。
カスタムメトリクスはOSがLinuxまたはWindowsであればCloud watchエージェントをインストールすることで登録可能です
CloudWatchで保存したログは最大１５ヶ月保持されます。
ログの対象はEC2,RDS,Route53,Lambda,CloudTrailです。

AWS Config

System Managerに①マネージドインスタンスで登録し、②ソフトウェアインベントリの収集を開始されたサーバの設定の変更管理を行うサービスです。
オンプレミスの変更履歴も収集可能で、変更の発生時にCloud Watch EventsやSNSに連携可能です。
CloudTrailに関連付けることでいつ誰のどの作業によりどのような設定に変更されたかが収集可能です。
クエリという機能でSQLクエリによる探索が可能です。

・2020年11月のリソースあたりの最も頻繁に変更された順に表示させる場合以下のようになります。

SELECT configurationItem.resourceType,
configurationItem.resourceId,
COUNT(configurationItem.resourceId) AS NumberOfChanges
FROM default.awsconfig
CROSS JOIN UNNEST(configurationitems) AS t(configurationItem)
WHERE "$path" LIKE '%ConfigHistory%'
AND configurationItem.configurationItemCaptureTime >= '2020-11-01T%'
AND configurationItem.configurationItemCaptureTime <= '2020-11-30T%'
GROUP BY configurationItem.resourceType, configurationItem.resourceId
ORDER BY NumberOfChanges DESC

Cloud Trail

AWSアカウント作成から90日間の全操作ログを保管しています。90日より前のログを保管するためにはS3バケットを指定して保存する必要があります。
ログファイルはSSE-S3により暗号化されますが、ユーザコントロール可能な暗号化を行う必要がある場合KMSで暗号化し、KMSへのアクセス権限をIAMによって制限しましょう。

管理イベント

コンソールへのログインとAWSリソースの作成・変更・削除が記録されます。

データイベント

データに対する操作（Lambaの実行、S3バケットでのデータ操作など）が記録されます。

インサイトイベント

AWSアカウント内の以上なアクティビティが記録されます。

Amazon Inspector

実行中のインスタンスのセキュリティ評価を行うサービスです。
オンプレミスのサーバの評価はできない点を注意してください。
ネットワークの到達可能性のルールパッケージはエージェントのインストールは「不要」です。
ホスト評価のルールパッケージはエージェントのインストールが「必要」です。
評価ターゲットのキーにEC2のタグを指定することで対象の絞り込みができます。
CI/CDパイプラインのセキュリティ面を考える場合、EC2インスタンスのパイプラインでAWS Inspector APIを使用する方法が考えらえます。

Amazon Athena

S3のデータをAWS Glueのデータカタログをメタデータとして、SQLクエリを実行することができるサービスです。
S3データの可視化に利用します。CloudTrailのイベント履歴の画面からAthenaテーブルを作成・クエリの実行まで行うことができます。

VPCFlowLogs

VPC内のIPトラフィックに対するロギングサービスです。
①保存先のS3に対してAthenaでクエリを実行しVPC内のネットワークレイヤの調査を行う際などに役立てることができます。
送信元IP/ポート、送信先IP/ポートのACCEPT/REJECT(通信許可/遮断)がログに含まれています。
②GuardDutyのMySQLやSSHと言ったポートへの不審なアクセスの検知は、VPCFlowLogsをインプットに自動検知することができます。
③REJECTをトリガーにCloudWatchのアラームに連動させることができます。

Amazon QuickSight

GUI操作可能なグラフを生成できる可視化（BI）サービスです。
データソースとしてAthena,Redshift,S3,AuroraさらにはオンプレミスのDBデータ(MySQL,PostgreSQL)を選択することが可能です。
使用例としてCloudtrailが考えられるが「ユーザ→QuickSight→Athena→S3→CloudTrail」のように関連付けることになります。

Amanzon Kinesis

リアルタイム処理のためのサービスです。Kinesisは４つのサービスから成り立ちます。

Kinesis Data Firehose

AWS WAFを利用する際にはELBにこれを適用するため、WAFを設定するロールにこのサービスのロールを設定する必要があったりします。

Kinesis Data Analytics

リアルタイム分析のサービスです。Apache Flink(Java)やSQLを用います。

Kinesis Data Streams

多数のプロデューサ(ログの出力元・センサーなどデータの出元)からのストリームデータ（シャード）をコンシューマ(S3などのAWSサービス)配信できます。
追加されたデータは永続的ではなく24時間(初期値)から７日間(最大)まで保持となります。

Kinesis Video Streams

動画ストリーミングのためのサービスです。

Amanzon Elasticsearch Service

Elasticsearch(OSS)をデプロイしてマネジメントサービスとして利用するためのサービスです。
データロードしてAmanzon Elasticsearch Serviceで処理しKibanaで可視化と言った利用がよくみられます。
データロードに関してはKinesis Data Firehoseから直接取り込む、またはKinesis Data Streams,S3,DynamoDBをLambdaを挟んで間接的に取り込みElasticsearchノードとして処理させます。

AWS X-Ray

サービス管理クエストを可視化するサービスで、レイテンシや障害発生率も検出可能、オンプレミスにも対応可能です。
サービスを有効にする条件は以下の３つです。
①EC2、ECS、Lambdaと一部Elastic Beanstalk(Java,.Net,Node.js)であること
②対象アプリケーションでX-Ray SDKを統合すること
③X-Rayエージェントを導入すること

S3

S3にはバケットのサーバーアクセスのログ記録という機能があり、S3 バケットに対するリクエストの詳細を記録することができます。
Step1.Amazon S3のコンソールの[バケット名] リストで、サーバーアクセスログ記録を有効にするバケットの名前を選択します。
Step2.「プロパティ」の「Server access logging (サーバーアクセスのログ記録)」を選択します。
Step3.「Enable Logging」を選択します。「Target Bucket」 で、ログレコードオブジェクトを受け取るバケットの名前を選択します。 保存して完了です。
Target Bucketはソースバケットと同じリージョン内である必要がある点に注意しましょう。

インフラストラクチャのセキュリティ

AWS Shield

DDoS攻撃対策のサービスです。

AWS WAF

CloudFront/ALB/API Gatewayに対応

Securitry Group

許可するルールのみ設定します。（ネットワークACLは許可・不許可を両方設定します。）
１つのインスタンスに複数設置が可能です

AWS Firewall Manager

AWS Shield Advanced/AWS WAF/VPC Security Groupのポリシーを一元管理するサービスです。
アカウントを跨いだ管理が可能です。

Route 53

条件により宛先を設定可能なDNSサービスです。異常時にSorryページに名前解決するフェイルオーバールーティング、大陸国別(米国のみ週ごと可能)に名前解決する位置情報ルーティング、新バージョンで問題ないか段階的にリリースするカナリアルーティングなどのルーティングが可能です。
Route53 Traffic Flowでルーティングの可視化が可能です。
VPCと紐付けてVPC内の名前解決も可能です。
IAMポリシーを適用して制限をかけることが可能です。

CloudFront

静的および動的データのCDNサービス
オリジンの保護

EC2の場合

CloudFrontとオリジンの間にWAFを設定しカスタムヘッダーのないリクエストを拒否する設定とします。

S3の場合

オリジンアクセスアイデンティティ(OAI)というユーザを設定し、S3への直接アクセスをCloudFrontのOAIのみに設定します。

署名付きURLと署名付きCookieの使い分け

オリジンがS3の場合に署名付きURLと署名付きCookieの設定が可能ですがそれぞれ以下のように使い分けます。

署名付きURL

個別のリソースやRTMPディストリビューションに適しています

署名付きCookie

複数のリソースやHLS形式の動画ファイル郡などに適しています。

Auto Scaling

「コスト最適化」「可用性最適化」「バランス型」の３タイプが用意されたリソースマネージメントサービスです。
可用性を担保する効果があります。
EC2、ECS、DynamoDB、Aurora、Spot Fleet(スポットインスタンスのコレクション)が対象になります。
ELBは最適化の対象ではありません。

ELB

３種類のロードバランサーを提供するサービスです。

ALB

VPCに属するEC2インスタンス、コンテナ、IP、Lambdaを指定できるL7レイヤーのロードバランサーです。

NLB

TLSターミネーションに対応したレイヤー４のロードバランサーです。

CLB

VPC外でも利用可能なレイヤー４およびレイヤー７のロードバランサーです。

API Gateway

ステートレスのRESTfulとステートフルのWebsocketの２種類をサポートするAPIサービスです。
Cloud Trail,Cloudwatchによるロギング、モニタリングが行えます。
HTTPS、Cognitoユーザプールを利用した認証はできませんが、JWTを利用した認証は可能です。
カナリアリリースも行うことができます。

VPC

仮想のネットワーク環境を提供します。EIPを通じてインターネットゲイトウェイにてルーティングされます。
CloudFrontを前におきELBはパブリックVPC、EC2は原則プライベートVPCとするのが原則です。

AWS Artifact

SOC/ISO/PCIのコンプライアンスレポートが出力できるサービスです。

IDおよびアクセス管理

IAMのベストプラクティス

超ざっくりまとめると「管理対象は少なく、与える権限も可能な限り狭く短く厳しく制限して、不要になったら即削除しろ」と言った内容です。
1.ルートアクセスキーをロックする
2.個々のIAMユーザを作成する(共有しない)
3.IAMユーザへのアクセス権はグループを使用し(参加させ)付与する
4.最小権限を付与する
5.AWS管理ポリシーを使用したアクセス許可の開始
6.インラインポリシーではなく、カスタマー管理ポリシーを使用する
7.アクセスレベルを使用して、IAM権限を確認する
8.強力なパスワードポリシーを使用する
9.多要素認証（MFA）の有効化する
10.EC2で実行するアプリに対してロールを使用する
11.ロールを使用しアクセス権限を委譲する
12.アクセスキーを共有しない
13.認証情報を定期的にローテーションする
14.不要な認証情報は削除する
15.追加セキュリティに対するポリシー条件を使用する
16.AWSアカウントのアクティビティ監視を行う
17.IAMベストプラクティスに関してのビデオを確認する

IAM

アカウント管理、認証、アクセス管理を統括する仕組みをまとめてサービスです
IAMポリシーが適用可能な先であるプリンシパルエンティティにはIAMユーザ、IAMグループ、IAMロールがあります。

IAMユーザ

認証にはID/パスワードとアクセスキーID/シークレットアクセスキーの２種類があります。
Githubへキーペアを保存してしまう等、IAMユーザの本人以外がアクセスする可能性がある箇所に情報を残さないように注意します。
IAMユーザーは「IAMグループから継承したポリシー」と、「自身に適用されたポリシー」の両方の権限を持つことになります。

IAMグループ

IAMユーザでなく、IAMグループに権限を付与してIAMユーザを参加させることが推奨されます。

IAMポリシー

AWSリソースへのアクセス権限の設定を記載したJSONです。
JSON形式で以下の４つのセクションを設定します。

Effect：Allow/Deny(明示されない場合はDeny)

デフォルトでは拒否
デフォルトの拒否より明示的な許可が強い
明示的な許可より明示的な拒否が強い

Action：サービス名：アクションの形式で書く　例）s3:Get

Resource：ARNで記述

Condition：有効になる場合の条件

管理ポリシー（AWS管理ポリシーとカスタマー管理ポリシーの２種類）

「ポリシー」単体として存在できて、複数のプリンシパルエンティティにつけたり外したりできます。
更新が発生した場合、1対多の関係でプリンシパルエンティティにアタッチした状態でもアタッチ済みのプリンシパルエンティティすべてに反映されます。
バージョン管理が可能です。
・AWS管理ポリシー
予めAWSによって用意されている管理ポリシーです。
・カスタマー管理ポリシー
利用者が独自に作成する管理ポリシーです。作成はJSON直接記述とジェネレータによる生成の２種類から選択できます。

インラインポリシー

「ポリシー」単体では存在できず、プリンシパルエンティティと1対1の関係にあります。
対象ごとに作成し、付与する必要があります。
管理ポリシーのように変更を反映されたくない、バージョン管理したくない場合に利用するポリシーです。

AWS Directory Service

Active Directoryの情報を利用してAWSのIDプロバイダーとして利用する場合の設定方法は以下のとおりです。
Step1：Active Directory側でAWSをActive Directoryの信頼できる証明書利用者として構成します。
Step2：Active Directoryグループに対応するアクセス許可を持つIAMロールを作成します。
Step3：IAMでSAMLプロバイダーを作成します。
複数のAWSアカウントのActive Directoryの情報を利用してAWSのコンソールに入りたい場合の設定方法は以下のとおりです。
Step1：AWS Organaizationsでまとめたいアカウントを組織化します。
Step2：組織内でAWS SSOを作成します。
Step1：Active Directoryの情報をAWS SSOに紐付けます。

AWS Cognito

AWSアプリケーションに認証認可を提供するユーザープール・ID プール・Syncの３つのサービスの総称です。

AWS Organizations

データ保護

KMS(Key Managemant Service)

CMKはカスタマー管理、AWS管理、AWS所有の３種類です。KMSの操作履歴は全てCloudTrailに保存されます。
KMSで採用されるエンベロープ暗号化の流れは、以下の通りです。
①データを暗号化するキー（CDK）でデータを暗号化（GenerateDataKeyで生成）
②別のキー（CMK）によりデータを暗号化するキー（CDK）を暗号化
③プレーン（暗号化されていない）データと暗号化するキー（CDK）を破棄
④CDKにより暗号化されたデータとCMKにより暗号化された暗号化するキー（CDK）を保存
CMKで暗号化したCDKを復号することで、データの復号ができるようになります。
キーマテリアル（暗号・復号に利用されるキーデータ）のオリジンに外部（External）を指定することでユーザ独自のもの、BYOK（Bring Your Own Key）をインポートできるためユーザ指定の暗号化アルゴリズムを使用できます。
ただし、BYOKには256bitの対照キーのみ、手動ローテーションのみ、有効期限が切れると即削除されるなど制限が課せられます。オンプレからの移行の際などこれらについても検討する必要があります。
2019年11月より非対称鍵(公開鍵暗号方式RSA・ECC)がサポートされることとなりました。

カスタマー管理

カスタマー管理型のキーのメニューにある「利用者が」作成・管理・使用するCMKです。
自動ローテーションは１年間（変更不可）です。それ以外の期間にしたい場合は手動キーローテーションを行います。
この時、アプリケーション側のCMK情報を更新したくない場合は、エイリアスを使用して関連付けます。

AWS管理

AWSマネージド型のキーのメニューにあるaws/サービス名」で記載されている「AWSサービスが」作成・管理・使用するCMKです。ローテーションは３年間です。

AWS所有

AWSが所有しているCMKで、AWSサービスの裏側で暗号化のために用いているキーなので利用者側からは見えません。

AWS Secrets Manager

Parameter Strore

「RDSの認証情報」「Redshiftクラスターの認証情報」「DocumentDBの認証情報」「その他データベースの認証情報」「その他シークレット(APIキー、DB認証以外)」のタイプを選択し保存できる「有償」のサービスです。
自動更新(ローテーション)機能があり、通常は更新が難しいアプリケーションの接続情報をSercret ManagerのAPIに置き換えることで最大365日のローテーション間隔でパスワードの更新が可能です。
注意点はSercret Manager側とDB側に対しLambdaを通して行われるため、Lamdaの権限不足によるエラーが発生した場合DB接続ができなくなるような自体が発生する可能性があるので注意しましょう。
EC2やLambdaなど多数のアクセス元から共通のDB認証で接続するようなサービスの場合はSecrets Managerのアクセスが可能なIAM Roleさえ設定していれば一元管理できるためベストプラクティスと言えます。
公式の注意書きにもSecrets Managerのローテーションに伴うアプリケーションの認証問題に関して書かれています。

警告
ローテーションを有効にした場合は、シークレットを保存するとすぐにシークレットが一度ローテーションされます。ローテーションを有効にする前に、このシークレット認証情報を使用してすべてのアプリケーションを更新し、Secrets Manager からシークレットを取得してください。初期ローテーション後は、元の認証情報は使用できない場合があります。更新に失敗したアプリケーションは、古い認証情報が無効になるとすぐに中断されます。

Secrets ManagerとParameter Stroreの違い

Secrets Managerは自動ローテーションがありますがParameter Stroreにはありません。
Secrets Managerは有償ですがParameter Stroreは無償です。
Secrets ManagerはAPIキーまたはデータベースに限定されますがParameter Stroreは多くのサービスで利用可能です。
Secrets Managerの最大リクエスト数は2000ですがParameter Stroreは1000です。

AWS CloudHSM

暗号鍵の保存に専用のハードウェアを使用しAWSがアクセスできないため、FIPS140-2などの高いコンプライアンスに準拠することができます。
実行自体はVPC内で行うことができます。

Amazon Elacstic Block Store

EC2で使用される「ブロックストレージ」です。
Amazon S3は「オブジェクトストレージ」でありAmazon EFSは「ファイルストレージ」(NFSでマウント)である点が他のストレージと異なる点です。
暗号化の対象はEC2とEBS間の通信・保存データ・生成されるスナップショット・暗号化されたスナップショットから生成されたEBS自身となっています。
暗号化に使用できる鍵はAWS管理のCMKまたはカスタマー管理のCMKです。

CMKがリージョン内に制限されることに伴うEBSでの対応の必要性

デフォルト暗号化を利用できますが、CMKがリージョン固有のため利用するリージョンごとに設定が必要です。
同じ原因でリージョン間でスナップショットをコピーするためにはコピー先にCMKの設定が必要になります。
暗号化されていないEBSを暗号化するためには一度スナップショットを取得して、コピーする際に暗号化といった手順を踏む必要性があります。

Amazon RDS

リレーショナルデータベースを提供するサービスです。
暗号化の方法は２種類あります。

データ保存時：KMSを利用した暗号化

暗号化を有効にした場合、暗号化の対象は以下の通りです。
保存されたデータ、自動バックアップ、リードレプリカ、スナップショット、ログファイル

データ伝送時：SSLまたはTLSを利用した暗号化

MySQLの場合は–ssl-caオプションで証明書を指定します。

IAMを利用した認証を推奨

各RDS毎の認証管理の必要がなく、パスワード情報を持たないため漏洩リスクもなく、EC2に設定したIAMロールでRDSが接続可能になるというメリットがあります。
RDSの認証はDBユーザ/パスワードの認証に加え、MySQL,PostgreSQL,Aurora MySQLAurora PostgreSQLではIAMを利用した認証が可能です。
設定は「データベースの設定」画面で「IAM DB認証」を選択(ラジオボタン)を設定するだけです。

Amazon DynamoDB

NoSQLを提供するサービスです。NoSQLはSQLインジェクションの代わりにNoSQLインジェクションが発生するので入力値の無害化処理は怠らないようにしましょう。
DynamoDBは暗号化が強制的に行われます。従って有効・無効などはなくCMKのタイプが選択できるだけです。

データ格納時の暗号化

「暗号化の管理」の画面にて
デフォルト(無償)：キーはAmazonDynamoDBが所有
KMSカスタマーマネージド(有償)：キーはアカウントに保存、お客様管理
KMS AWSマネージド(有償)：キーはアカウントに保存、KMSによって管理

DynamoDB Acceleratorの暗号化

DAXとも呼ばれるインメモリキャッシュサービスです。

AmazonS3

S3にはセキュリティ上重要な以下のようなログを保存する際にも利用されるためアクセス権限管理が非常に重要になります。
暗号化方式はSSE-S3(無料),SSE-KMS,SSE-C,CSEの4つです
S3は、1秒当たりのリクエスト数に上限があり5500回/秒となっているためDDoS対策としてCloud Frontの利用などを検討すると良いでしょう。
バケットポリシー:バケットの所有者のみが操作可能、正規表現を用いたオブジェクト単位の制御が可能
Multi Factor Authentication Delete：不意に削除してしまわないための設定
アクセスコントロールリスト:バケットの所有者以外も操作可能、バケットACLとオブジェクトACLが存在するがアクセスログをS3に保存する際などに利用

アクセス制御と使い分け

IAMポリシー:ユーザに対して許可・拒否するAPIをIAMポリシーに記載します。
割り当てられたフォルダのみにアクセスさせる場合、ポリシー変数 ${aws:username} を使用すると以下の様にかけます。

{
　　 "Sid": "AllowAllS3ActionsInUserFolder",
 　　"Effect": "Allow", "Action": [ "s3:*" ],
 　　"Resource": [
 　　　　　　"arn:aws:s3:::my-company/home/${aws:username}/*"
 　　] 
}

バケットポリシー：アクションはステートメント内のどのリソースにも適用されません

公式の記載によるとバケットそのものを指定ができないので/*を追加してあげればバケット内へのアクションを規定できることになります。

個々のリソースに対してアクションを指定できません。代わりに、ActionまたはNotAction要素にリストしたアクションは、そのサービス内のすべてのリソースに適用されます。このような場合は、Resource要素にワイルドカード*を使用します。

オブジェクトロックとボールトロック

ボールトロック：
S3より安価なGlacierでは、監査上のデータ(アーカイブ)などを修正も削除もできなく(ロック)するボールトロックという機能があります。
intiateからCompliteまでの間は中止(Abort)することでポリシーの変更などが可能です。
オブジェクトロック:
Glacierに移動せずにS3にあるオブジェクトをロックすることができる機能です。リテンションモードという２つのモードがありコンプライアンスモードはrootを含めて全てのユーザが変更できなくなります。一方、ガバナンスモードでは一部のユーザに許可することができます。
リテンションモードでは期日が設定できますが、S3:PutObjectLeagalHold権限を保つIAMユーザにより法的保有を有効にした場合、設定の期日にかかわらずオブジェクトロックとすることが可能です（後から無効に変更可能です）

EC2

インスタンスメタデータサービス(IMDS)のローカルリンクが悪用されて、米金融大手 Capital OneのSSRF攻撃の原因にもなりました。
IMDSv1では簡単にGETアクセスできてしまいましたが、IMDSv2ではメタデータへのアクセスの前にセッショントークンが必要になり、セッショントークンの取得はメタデータへのHTTP PUTリクエストで行う必要があるためリスクはかなり低減しました。
v１はEC2内部から http://169.254.169.254/latest/meta-data/をアクセスすると”AccessKeyId”,”SecretAccessKey”と言ったクレデンシャルが容易に取得できてしまいました。

VPCエンドポイント

VPCではエンドポイントにアクセスポリシーを設定可能でプラベートサブネットからインターネット(AWS外部)を介さずに直接S3と通信することが可能です。
一方、IAMポリシーやバケットポリシーが正しいにもかかわらず通信できないS3が存在する場合はエンドポイントのポリシーを疑ってみるべきです。
VPCピアリングが確立しているにもかかわらずドメインへの参加は機能していない場合は、ADホストサブネットのセキュリティグループに関連するサブネットの正しいルールが あることを確認しましょう。

以上です。参考になれば幸いです。