【レポート】AWSアカウントを守るためにおさえておきたいセキュリティ対策 #AWS-52 #AWSSummit

本記事はAWS Summit Online Japan 2021で5/12に行われたセッション「AWS アカウントを守るためにおさえておきたいセキュリティ対策」のセッションレポートとなります。

AWSアカウントの保護をどこから始めたらいいか悩んでいる方も多いのではないでしょうか？そんな方は、ぜひ本セッションでAWSを利用する上でまずはやっておきたい対策を学んで実践してみてください。

セッション概要

スピーカー

• アマゾン ウェブ サービス ジャパン株式会社 パートナーアライアンス統括本部 ストラテジックSI技術部 シニアパートナーソリューションアーキテクト 大場 崇令
• アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 レディネスソリューション本部 シニアセキュリティスペシャリストソリューションアーキテクト 高橋 悟史

AWS アカウントを保護する上で、自分たちが何をやったら良いか、どこから始めれば良いか悩まれている方も多くいらっしゃると思います。AWS Well-Architected フレームワーク のセキュリティの柱では、AWS 環境におけるセキュリティ対策のポイントが提示されています。当セッションでは、AWS Well-Architected フレームワーク のベストプラクティスに基づき、AWS を利用する上で、おさえておきたいセキュリティ対策を解説いたします。

セッションレポート

本セッションの対象者とゴール

• 対象者
  • AWS の基本的な概念は知っている方
  • AWS Well-Architected フレームワークをこれから学ぶ方
  • AWS アカウント保護に不安がある方
• ゴール
  • このセッションを聞いたあと、自社のアカウントのセキュリティ対策をすぐに実施出来る
  • セキュリティにおける、AWS Well-Architected レビューが出来るようになること

Agenda

• AWS Well-Architected フレームワークとは
• AWS Well-Architected フレームワーク セキュリティの柱について
• AWS アカウントを守るために実施すべきセキュリティ対策

AWS Well-Architected フレームワークとは

• システム設計・運用の”大局的な“考え方とベストプラクティス集
• AWS のソリューションアーキテクト (SA)、 パートナー様、お客様の 10 年以上にわたる 経験から作り上げたもの
• AWS とお客様と共に、W-A も常に進化し続ける

• 上記の柱の中には5つの柱が存在
  • 運用上の優秀性
  • セキュリティ
  • 信頼性
  • パフォーマンス効率
  • コスト最適化
• W-A における設計原則(Design Principles)
  • 必要キャパシティーの推測が不要に
  • 本稼働スケールでシステムをテストする
  • 自動化によってアーキテクチャでの実験を容易にする
  • 発展的なアーキテクチャが可能に
  • データに基づいてアーキテクチャを進化させる
  • ゲームデーを利用して改善する

WS Well-Architected フレームワーク セキュリティの柱について

• セキュリティの柱における設計原則
  • 強力なアイデンティティ基盤を導入する
  • 追跡可能性を有効にする
  • すべてのレイヤーにセキュリティを適用する
  • セキュリティのベストプラクティスを自動化する
  • 転送中および保管時のデータを保護する
  • 人をデータから遠ざける
  • セキュリティイベントに備える
• セキュリティの柱における 10 の質問

• AWS Well-Architected フレームワークの活用
  • Well-Architected レビュー
    • AWS Well-Architected フレームワークにおける各柱ごとの質問にワークロードを照らし合わせる作業のこと
    • 現在 (As is) のベストプラクティスの適用状況を理解し、将来 (To be) のアーキテクチャーを検討する
    • 設計、構築、運用等、ワークロードの特性が変わるタイミングで定期的に実施することを推奨
  • AWS Well-Architected Tool
    • Well-Architected レビュー時に活用できる AWS のサービス
    • 各質問毎にベストプラクティスの適用状況を記録できる
    • レビューした結果をレポートとして出力でき、リスクレベルが可視化される

AWS アカウントを守るために実施すべきセキュリティ対策 マルチアカウント編

• マルチアカウント保護における最低限おさえておきたいセキュリティの2項目
  • ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
    • 一元化された IDプロバイダーを利用する
    • 一時的な認証情報を使用する
  • 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
    • 組織のアクセス許可ガードレールを定義する

一元化された IDプロバイダーを利用し 一時的な認証情報を使用する

• 一時的な認証情報を使用する AWSアカウントにおけるシングルサインオン
• SAMLやOIDCを用いたIDフェデレーションをサポート
  • 外部のアイデンティティに、IAMロールのセッションを用いてAWSリソースへのアクセスを可能とする

• 複数の AWS アカウントへのログインを一元化したい場合
  • AWS Single Sign on (SSO)
    • 無料で利用可能
    • 既存ADを活用
    • 複数アカウントへのSSOアクセス

• 一時的な認証情報を使用する AWS アカウントへのアクセスに IAM ロールを使用
  • クロスアカウントアクセスにロールを使用
    • 別のアカウントのリソースにアクセスするときにセキュリティを強化可能
  • 認証情報の共有なし
  • VPC 認証情報の重複なし
  • 必要に応じて MFA を使用

組織のアクセス許可ガードレールを定義する

• 開発者の開発スピードを落とさずに守る仕組みが必要
• ガードレールの設置
  • 予防的ガードレール
    • 対象の操作を実施できないようにするガードレール
    • Organizations Service Control Policy (SCP)で実装する
  • 発見的ガードレール
    • 望ましくない操作を行なった場合、それを発見するガードレール
    • 管理しつつ開発のスピードを上げるために効果的
    • AWS Config Rules で実装する
• AWS Organizations SCP の検討
  • 予防的ガードレール
  • AWSリソースや API へのアクセス制限を実現
  • OU単位のAWSアカウント全体にガードレールを設定可能
• AWS Config Rules の検討
  • 発見的ガードレール
  • 組織のルールから逸脱していないかどうかを評価
  • 全体的なコンプライアンスおよびリスク、ステータスの評価、経時的なコンプライアンス 傾向の確認、どの設定変更によってリソースが ルールに違反したかの特定が可能
  • ルールによるリソースの 設定変更の評価結果はダッシュボードで確認可能

AWS アカウントを守るために実施すべきセキュリティ対策 AWSアカウント全般編

• AWSアカウント保護における最低限おさえておきたいセキュリティの2項目
  • ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
    • 強力なサインインメカニズムを使用する
    • 一時的な認証情報を使用する
    • シークレットを安全に保存して使用する
    • 定期的に認証情報を監査およびローテーションする
  • セキュリティイベントをどのように検出し、 調査していますか?
    • サービスとアプリケーションのログ記録を設定する
    • ログ、結果、メトリクスを一元的に分析する

強力なサインインメカニズムを使用する

• ルートユーザーのMFAを有効化
• アクセスキーを削除
• 管理権限を持つIAMユーザーのMFAを有効化

一時的な認証情報を使用する

• AWS SSO,SAML,IDフェデレーションを利用することで一時的な認証情報を使用
• EC2やプログラムなどにアクセスキー を埋め込まない
• アクセスキーの代わりにIAMロールを使用

シークレットをハードコードしない

• データベースへ接続するユーザーID、パスワードや、外部サービスに接続する際の認証情報
  • プログラムコードや平文でアクセス可能な設定ファイルなどに保管しない
• AWS Secrets Manager やAWS Systems Manager Parameter Store を使用
  • 安全にシークレットを保存、利用が可能

定期的な認証情報を監査し、ローテーションする

• API アクセスキーや AWS マネージメントコンソールへの ログインパスワードを定期的にローテーションする
• AWS マネージメントコンソールのログインに MFA を利用している場合には、MFA のトークンが短時間で ローテーションしていくのでそれで対応可能
• AWS Config ルールによる パスワードポリシーと アクセスキーローテーションのチェック
  • Config ルールがパスワードポリシーの設定
  • IAMユーザーのアクセスキーのローテーション状況を自動チェック

サービスとアプリケーションのログ記録を設定する

• CloudTrail,Configを有効化する
• Organizationsのマルチアカウント環境では組織の証跡を作成
  • CloudTrailが自動で有効化
• コンソールからすぐに開始可能なため設定しておく

ログ、結果、メトリクスを一元的に分析する

• GuardGutyを有効化する

• 検出結果に対してアクションをとる体制をつくる
  • Guard Duty, Security Hub, IAM Access Analyzer といったセキュリティーサービスは検出結果を生成
  • 重要度が高い場合にはセキュリティインシデントの可能性がある
    • 検出結果を担当者に通知しておく設定
    • 検出結果が出た場合の対応者、対応手順を検討しておく
  • GuardDuty のイベント通知設定
    • CloudWatch Events あるいは、 EventBridge でルールを作成
    • GuardDutyで発生したイベントを 適切な宛先に転送したり自動で処理させる

まとめ

• AWS Well-Architected フレームワークとは
  • 10年以上の経験、数多くのお客様と作りあげた クラウド設計・運用のベストプラクティス集
• AWS Well-Architected フレームワーク セキュリティの柱
  • 10 個の質問とベストプラクティスを利用可能
• AWS アカウント保護に有効なベストプラクティスをご紹介
  • すぐに実践できるセキュリティ対策を検討する

このセッションを見た後に 検討していただきたいこと

• ルートユーザーのアクセスキー削除、MFA 設定
• 管理者権限を持つ IAM ユーザーの MFA 設定
• AWS CloudTrail の有効化
• AWS Config の有効化
• Amazon GuardDuty の有効化
• セキュリティサービスからのイベントを担当者に通知する設定

感想

AWSでセキュリティ対策をする上でまずやっておきたいことがまとまったセッションでした。特に一時的な認証情報を利用してアクセスキー を利用しない、認証情報をプログラムに埋め込まないなどは意識しておきたいポイントですね。最近アクセスキー漏洩による不正利用が目立ってきているので、今一度見直しておきましょう。