[前回] AWS公式資料で挑むSCS認定(28)-こんな時どうする(全分野その5)

はじめに

引き続き、「こんな時どうする」です。
「分野1: インシデント対応」ネタ切れ寸前。。。

分野1: インシデント対応

特定IPからVPCサブネットへDDoS攻撃が報告された
- NACL(ネットワークアクセスコントロールリスト)のインバウンドルールで、問題IPからのアクセスを拒否
- ※ SG(セキュリティグループ)は拒否ルール設定できない(許可のみ)
EC2インスタンスへのアクセス侵害が報告された、セキュリティグループでリソースへの無制限アクセスが許可されていないかチェックしたい
- AWS Trusted Advisorを使用し、セキュリティグループをチェック
  - リソースへの無制限アクセスを許可するルールがないか確認
    - 無制限アクセスは、悪意あるアクティビティ(ハッキング、サービス拒否攻撃、データ損失)のリスクを高める
  - 特定のポートに無制限アクセスを許可するルールがないか確認
    - 赤いフラグ: リスクが最も高いポート
    - 黄色いフラグ: それよりリスクが低いポート
    - 緑のフラグ: HTTPやSMTPなど無制限アクセスが必要なポート
- ※ AWS Trusted Advisorは、AWSのベストプラクティスに基づく5つのカテゴリにわたるチェックと推奨事項を提供
  - コストの最適化
  - セキュリティ
  - 耐障害性
  - パフォーマンス
  - サービスの制限

分野2: ログとモニタリング(監視)

AWS KMSへのすべての呼び出しを記録したい

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

AWSアカウントのすべてのリソースをリストアップしたい
- AWS Configを使用し、すべてのリソースのリストを取得
- AWS Configで記録する内容
  - アカウント内のすべてのリソース
  - 指定期間中に発生したリソースの設定変更
  - 選択したリソースとすべての関連リソースとの関係
  - リソースのコンプライアンス状態の変更
    - AWS Config Rulesで評価され、タイムラインに表示される
大量EC2インスタンスに対し、セキュリティパッチの未適用リストをレポートしたい
- Systems Manager Patch Managerを使用しレポートを生成
  - パッチ適用プロセスの詳細な結果を示し、パッチのコンプライアンス情報を表示
    - インストールされたパッチ
    - 欠落しているパッチ
    - 適用外のパッチ
    - インストールに失敗したパッチ
- ※ AWS Systems Manager(旧称 SSM)は、AWSでインフラストラクチャを表示および制御するサービス
  - 複数AWSサービスの運用データを表示、AWSリソース全体の運用タスクを自動化
  - マネージドノードをスキャンし検出されたポリシー違反を報告/是正し、セキュリティとコンプライアンスを維持
  - リソースとアプリケーションの管理が簡略化され、運用上の問題が検出され解決するまでの時間が短縮される
  - 大規模なAWSインフラストラクチャの安全な運用と管理を簡単に行う

分野4: アイデンティティ(ID)及びアクセス管理

Lambda関数でDynamoDBテーブルへ書き込みを行いたい
- DynamoDBテーブルへの書き込みアクセス許可を持つIAMロールを作成
- IAMロールをLambda関数に関連付ける
特定IAMユーザーのみAWSリソースへのアクセスを許可したい
- リソースベースポリシーを使用し、個別ユーザのみアクセス許可を付与
  - リソースベースポリシーは必ずインラインポリシー
Amazon S3バケットにホストしている静的ウェブサイトAに、JavaScriptを使って別のバケットにホストしているウェブサイトBにアクセスするウェブページが存在する
- 通常、ブラウザはCORSチェック(プリフライトチェック)によりJavaScriptをブロックし、ウェブサイトBへのリクエストを許可しない
- ウェブサイトBのバケットにCORSを設定し、ウェブサイトAからのクロスオリジンリクエストを有効に設定
- ※ Cross−Origin Resource Sharing(CORS)は、ウェブブラウザのセキュリティ機能で、ウェブブラウザはどのドメインが外部のウェブサイトまたはサービスのリクエストを行うことができるかネゴシエートできる
  - Amazon S3のCORS設定により、Amazon S3でリッチなクライアント側ウェブアプリケーションを構築し、Amazon S3リソースへのクロスオリジンアクセスを選択的に許可できる
- ※ 一部JavaScript環境でCORSの設定は不要。例、
  - Amazon S3バケットにアプリケーションをホストし、*.s3.amazonaws.comまたはその他の特定のエンドポイントからリソースにアクセスする場合、リクエストは外部ドメインにアクセスしない
- ※ Amazon S3でバケットのCORS設定の評価方法
  - Amazon S3がブラウザからプリフライトリクエストを受け取ると
  - バケットのCORS設定を評価し、受信ブラウザリクエストに一致する最初のCORSRuleルールを使用し、クロスオリジンリクエストを有効にする
  - ルールが一致するには、次の条件を満たす必要あり
    - リクエストのOriginヘッダーがAllowedOriginエレメントに一致
    - リクエストメソッド(GET/PUTなど)またはプリフライト Access-Control-Request-Methodリクエストの場合、OPTIONSヘッダーがAllowedMethodエレメントのいずれかである
    - プリフライトリクエストのリクエストのAccess-Control-Request-HeadersヘッダーにリストされているすべてのヘッダーがAllowedHeaderエレメントと一致
- ※ オリジン(Origin)とは、ウェブコンテンツにアクセスするために使用されるURLのプロトコル + ホスト + ポート
- ※ プリフライトリクエスト(Preflighted Requests)とは、
  実際のリクエストの送信前にOPTIONSメソッドによるHTTPリクエストをクロスオリジンに送信し、実際のリクエストを送信しても安全か確かめる仕組み

分野5: データ保護

特定ユーザーのみ暗号化キーへアクセスできるようにしたい(AWSからもアクセス不可)
- AWS CloudHSMを使用し暗号化キーを生成
  - 暗号化キーにアクセスできるのは、お客様が指定したHSMユーザーのみ
  - AWS側から暗号化キーは不可視でアクセスできない
  - CloudHSMは、VPC内で排他的に制御できる専用HSMを直接利用
- ※ AWS CloudHSMとは、クラウドベースのハードウェアセキュリティモジュール(HSM)で、暗号化キーを簡単に生成/使用できる
  - FIPS 140-2のレベル3認証済みHSMを使用し、暗号化キーを管理
  - 下記ライブラリの業界標準APIをアプリケーションで使用できる
    - PKCS#11
    - Java Cryptography Extensions(JCE)
    - Microsoft CryptoNG(CNG)

おわりに

「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。

[次回] AWS公式資料で挑むSCS認定(30)-こんな時どうする(全分野その7)