#はじめに
AWSの認定資格について、昨年ソリューションアーキテクト プロフェッショナル（SAP-C01）を取得した。
そこからAWSの知識インプットの機会が減ってしまったので、上位資格の取得を目指すことにした。
そこで、選んだ結果セキュリティを取得することにした。
#準備
こちらから認定について、抜粋する。
AWS 認定 セキュリティ – 専門知識
##知っておくべきこと
- AWSセキュリティのベストプラクティスを使用して AWS プラットフォームを保護する。
- AWSアカウントで大規模な認証と許可を管理する。
- 適切なデータ暗号化方法と AWS メカニズムを使用して、保管時のデータのセキュリティを運用する。
- 適切、安全なインターネットプロトコルと AWSメカニズムを使用して、転送中のデータのセキュリティを運用する。
- AWSでセキュリティモニタリングとログ記録を運用し、検出されたセキュリティインシデントへの対応を自動化する。
- AWSのセキュリティ固有のサービスと機能を使用して、本番環境のセキュリティを保護し、トラブルシューティングする。
##問題の配分
以下の配分で問題が出題されるので、学習を進める上での配分に使えそう。
| 分野 | 出題の比率 |
|---|---|
| インシデント対応 | 12% |
| ログ記録とモニタリング | 20% |
| インフラストラクチャのセキュリティ | 26% |
| Identity and Access Management | 20% |
| データ保護 | 22% |
#分野（１）｜インシデント対応
大枠で必要な知見
- AWSの不正使用の通知に応じて、侵害された疑いのあるインスタンスまたは公開された疑いのあるアクセスキーを特定する。
- インシデント対応計画に適切なAWSのサービスが含まれていることを確認する。
- 自動アラートの設定内容を評価し、セキュリティ関連のインシデントや新しく発生する問題への対策を講じる。
重要なのはオンプレミスではできた、物理的なネットワーク隔離をAWSクラウドではできないということ。
そこをどのように隔離するのかを理解する必要がある。（セキュリティグループやネットワークACLなど）
##インシデント対応向けAWSツール
- AWS Trusted Advisor
- AWS CloudFormation
- AWS Service Catalog
- VPC フローログ
- AWS Config
- Amazon API Gateway
- AWS CloudTrail
- Amazon CloudWatch
##一般的なインシデント
- 漏洩したユーザ認証情報
- 不十分なデータの整合性
- 制限のなさすぎるアクセス
##インシデントの兆候
- ログとモニタリング
- 請求活動
- 脅威インテリジェンス
- AWSサポート
- パブリックレスポンス
###侵害されたインスタンス
特定のEC2のSGをフォレンジックSGに変更して、調査を行う。
また、EBSスナップショットやボリュームコピーなどを行う。
###公開されたアクセスキー
例えば、Githubにアクセスキーが公開されたら、グローバルで侵害される。
対応例のウォークスルーは以下となる。
- 認証情報を無効にする
- 特権的アクセスを取り消す
- IAMアクセスキーのソースを確認する
- 整合性を確認し、影響範囲を調べる
#分野（2）｜ログ記録とモニタリング
- セキュリティモニタリングとアラートの設計と実装
- セキュリティモニタリングとアラートのトラブルシューティング
- ロギングソリューションの設計と実装
- ロギングソリューションのトラブルシューティング
##AWSのモニタリングツール
- Amazon CloudWatch
- AWS Config
- AWS CloudTrail
- AWS Inspector
- Amazon Kinesis
- Amazon Athena
###CloudWatchの仕組み
###CloudWatch Logsの仕組み
CloudWatch エージェントをインストールして開始し、メトリクスを設定すると、
モニタリング対象のインスタンスまたはサーバーがログイベントを CloudWatch Logs に送信します。
###CloudWatch Events の仕組み
###Amazon Kinesis Data StreamsとAmazon Kinesis Data Firehose
#分野（３）｜インフラストラクチャのセキュリティ
- AWSのエッジセキュリティの設計
- セキュアなネットワークインフラストラクチャの設計と実装
- セキュアなネットワークインフラストラクチャのトラブルシューティング
- ホストベースのセキュリティの設計と実装
##エッジセキュリティのツール
- Amazon Route 53
- AWS WAF
- Amazon CloudFront
- AWS Shield
##WAFの条件
| 条件 | リクエストを許可またはブロックする基準 |
|---|---|
| クロスサイトスクリプティングの一致 | リクエストに悪意のあるスクリプトが含まれているおそれがあるかどうか |
| IP の一致 | 送信元の IP アドレス |
| 地理的な一致 | リクエストの発生元の国 |
| サイズの制約 | リクエストが指定した長さを超えているかどうか |
| SQLインジェクションの一致 | リクエストに悪意のある SQL コードが含まれているおそれがあるかどうか |
| 文字列の一致 | リクエスト内の文字列 |
| 正規表現の一致 | リクエスト内の正規表現パターン |
##DDoS緩和のツール
- ELB
- Amazon CloudWatch
- Amazon EC2 Auto Scaling
- AWS Shield
- Amazon Route 53
- AWS WAF
- Amazon CloudFront
##AMIのセキュリティに関する考慮事項
###安全でないアプリケーションを無効化
クリアテキストによる認証を使用したサービスとプロトコルを無効化
###漏洩を最小化
必須でないネットワークサービスを起動時に無効化
必要がない場合は、ファイル共有、Print Spooler、RPC などのデフォルトのサービスを無効化
###AMIの作成時に認証情報を保護
ディスクと設定ファイルから AWS とサードパーティのすべての認証情報を削除
すべてのユーザー SSH パブリックキーペアとプライベートキーペアを削除
すべてのユーザーアカウントのパスワードを削除および無効化
###データの保護
システムとイベントのログを削除
#分野（4）｜Identity and Access Management
- AWSリソースにアクセスするためのスケーラブルな認証および認可システムの設計と実装
- AWSリソースにアクセスするための許可および認証システムのトラブルシューティング
##AWSの操作
##APIの保護
- アイデンティティの確認｜アクセスキー
- 改竄防止｜ハッシュ値
- リプレイ攻撃の防止｜タイムスタンプ
##IAMアクセス許可の決定方法
ポリシーはAWSのエンティティであり、アイデンティティやリソースにアタッチして、これらのアクセス許可を定義します。
##IAMアクセス許可の決定方法
ポリシーはAWSのエンティティであり、アイデンティティやリソースにアタッチして、これらのアクセス許可を定義します。
##ポリシーエレメント
| 要素の種類 | 概説 | 必須 |
|---|---|---|
| 効果 | ステートメントの結果を許可または明示的な拒否のどちらにするかを指定する | あり |
| アクション | 許可または拒否される特定のアクションについて説明する | あり |
| リソース | ステートメントで取り扱う一連のオブジェクトを指定する | あり |
| 条件 | ポリシーを実行するタイミングの条件を指定する | なし |
| 原則 | リソースへのアクセスを許可または拒否するエンティティを指定するリソースベースのポリシーや信頼ポリシーに使用する | なし |
##ポリシー管理の考慮事項
- 必要なユーザのみアカウントを作成し、それ以外はロールとフェデレーションを使用する。
- インラインポリシーではなくカスタマー管理ポリシーを使用する。
- 各IAMエンティティには、まずアクセス権限のない最小限の権限のみを付与する。
- 様々なエレメントを使用して、ポリシーサイズを削減する。
#分野（5）｜データ保護
- キーの管理の設計と実装
- キー管理のトラブルシューティング
- 保管中のデータおよび転送中のデータのためのデータ暗号化ソリューションの設計と実装
##暗号化の基礎
##キー管理ツール
- AWS KMS
- CloudHSM
###KMS
- 一意のエイリアスと説明をつけたマスターキーを作成する
- マスターキーを自動的にローテーションする
- キーを無効化または削除する
- AWS CloudTrailを介してキーの使用を監査する
- キーをインポートする
AWS KMS にはキーを保護するために 2つのセキュリティメカニズムがさらに用意されています。
| ポリシー | 許可 |
|---|---|
| リソースベースの権限 | 一時的なアクセス権限、またはより詳細なアクセス権限 |
| IAMポリシーと類似した構文 | カスタマーマスターキー (CMK) をプログラムで委任する |
| キーの管理、および暗号化/復号を行えるユーザーを指定 | アクセスを許可するのに使用 |
##クライアント側の暗号化とサーバー側の暗号化
- キーをどこに保存するか。自分のハードウェアで保存するか。または AWSが提供するハードウェアを使用して保存するか。
- キーをどこで使用するか。クライアントソフトウェアで使用するか。または AWSで使用するか。
- 誰がキーを管理するか。ユーザーやアプリケーションレベルでアクセス権限を割り当てる必要があるか。または AWS でアクセス権限が管理されるようにするか。
###クライアント側
- AWSに送信する前にユーザーがデータを暗号化する
- データは暗号化された状態で保存
- ユーザーのみが知っているキーとアルゴリズム。
###サーバ側
- 受信した後にAWSがユーザーに代わってデータを暗号化する
- エンドユーザーに対して透過的。
- AWSは定期的にマスターキーをローテーションする。
##保管中および転送中のデータ
###転送中のデータ保護
トラフィックが暗号化され、HTTPS経由でデータの整合性が認証される
- クライアントとサービスエンドポイント間にTLSセッションを確立する
- パブリックキーインフラストラクチャ（PKI）内でX.509署名書を使用する
- 証明書によりサーバーのアイデンティティを検証し、改竄や偽造を防止する
##S3のデータアクセス保護
- オブジェクトACL
- バケットACL
- バケットポリシー
- IAMユーザーポリシー
#最後に
ここまでにセキュリティ認定に向けた概要とフォーカスをざっくりまとめた。
今後は、詳細を学んで取得を目指す。
（5月くらいかな・・・）