AWS公式資料で挑むSCS認定(29)-こんな時どうする(全分野その6)

[前回] 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へのすべての呼び出しを記録したい
  • AWS CloudTrailで証跡を有効にする
  • AWS KMSは、AWS KMSへのすべての呼び出しを記録するAWS CloudTrailと統合されている
  • ※ CloudTrailは、AWS KMS へのすべてのAPIコールをキャプチャ
    • AWS KMSコンソールからの呼び出し
    • AWS KMS API
    • AWS Command Line Interface(AWS CLI)
    • AWS Tools for PowerShell
  • ※ デフォルトで、すべてのAWS KMSアクションがCloudTrailイベントとして記録される
    • CloudTrailの証跡から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)