Amazon Web Services (以下AWS)の利用開始時にやるべき設定作業を解説します。AWSの利用開始とは、AWSアカウントの開設を意味しますが、より安全に利用するため、AWSアカウント開設直後にやるべき設定がいくつかあります。この連載ではその設定内容を説明します。
AWS Organizationsを使用することで、複数のアカウントに自動的にこういった初期設定を行うことも可能ですが、この連載では新規で1アカウントを作成した場合を前提とします。複数アカウントの場合も、基本的な考え方は同じになります。
設定作業は全１９個あり、作業内容の難しさや必要性に応じて以下３つに分類しています。 少なくともMUSTの作業については実施するようにしましょう。
- MUST ：アカウント開設後に必ず実施すべき作業
- SHOULD ：設定内容の検討または利用方法を決定のうえ、可能な限り実施すべき作業
- BETTER ：AWS知識のある方やセキュリティ要件の高いアカウントで実施すべき作業
開発・検証用途のAWSアカウントの場合も、「AWSアカウントが乗っ取られて、大量のリソースを作成される、不正利用される」といったリスクは存在するため、全てのAWSアカウントで設定することが重要です。
ルートユーザの保護
ルートユーザとは、AWSアカウント作成時に設定したメールアドレスとパスワードでログインできるユーザのことを指します。全てのAWSサービスとリソースの操作が可能であり、操作した個人を特定できません。後述するIAMユーザーを作成した後は、基本的に使用しないようにするべきです。 ルートユーザを保護するために以下の設定を行います。
作業１. パスワードの設定 [ MUST ]
アカウント設定ページから、強力なパスワードをルートユーザに設定します。具体的には、14文字以上、大文字・小文字・数字・特殊文字を含む、アカウント名やEメールアドレスと関連性の少ない文字列とします。
※追記：最近ではより長いパスワードが一般的なため、8文字→14文字に記載変更しました。
作業２. 多要素認証（MFA）の有効化 [ MUST ]
セキュリティ認証情報のページから、ルートユーザのMFA有効化を行います。これにより、MFAデバイスを持った管理者のみがルートユーザでログイン可能となります。MFAデバイスは物理と仮想の2種類ありますが、物理デバイスの用意が難しい場合はスマートフォンアプリ等で設定可能な仮想MFAデバイスを使用します。
コストの可視化
AWSのようなクラウド環境では、利用量に応じて料金が発生するため、リソースの削除漏れや設定ミス等により利用料が大きくなってしまう可能性があります。そのため、利用料（コスト）の状況はすぐに確認できるように可視化しておき、想定以上の利用料になった場合は検知する仕組みが必要となります。最低限以下の設定を実施しておきましょう。
作業３. IAMユーザーの請求情報アクセス許可 [ MUST ]
デフォルト状態では、IAMユーザーは請求情報のページへアクセスすることができません。ルートユーザは基本使用しない方針とするため、IAMユーザーがこのページを確認できるように、アカウント設定のページから設定しておく必要があります。アクセス許可の設定はルートユーザのみ可能なため、アカウント開設直後に設定しましょう。アカウント設定ページは、マネジメントコンソールログイン後、右上のアカウント名＞アカウントを順に選択することで遷移が可能です。ページ下部にある「 IAM ユーザー/ロールによる請求情報へのアクセス」をアクティブ化することで、IAMユーザーが参照可能になります。
作業４. Cost Explorerの有効化 [ SHOULD ]
Cost Explorerは、AWS利用料を月別、日別やサービス別で確認できるツールです。こちらも請求情報のページから有効にする必要があるため、上記IAMユーザーのアクセス許可設定と合わせて実施しましょう。
作業５. 予算およびアラートの設定 [ MUST ]
AWS Budgets(予算)の画面から、あらかじめ想定した利用料を決めておき、予算として設定が可能です。利用料が予算額に達した場合や、予算額の何%になったらメール通知を行うといった設定も可能です。意図しない利用料の増加に気づくためにも必ず設定するようにしましょう。他にもCloud Watch アラームを使用して利用料増加の検知を行うことも可能です。どの方法でも良いので、利用料の増加に気づく仕組みは必ず用意しておくようにしましょう。
IAMユーザーの作成
個人を特定でき、操作権限の設定が可能なIAMユーザーを作成します。
作業６. 管理者IAMユーザーの設定 [ MUST ]
まずは全ての操作が可能な管理者用のIAMユーザーを作成します。ユーザーごとに権限を付与するのは手間になるため、IAMグループを作成し、そのグループに全ての操作が可能なIAMポリシー「AdministratorAccess」を付与します。その後必要な人数分IAMユーザーを作成し、このIAMグループに所属させます。
作業７. 利用者IAMユーザーの設定 [ SHOULD ]
アカウントの利用用途（例えばVPCとEC2のみ使用するなど）が決まっていれば、利用用途の権限のみ付与したIAMユーザーも作成します。全ての利用者へ管理者権限を付与するのではなく、必要最低限な権限を付与することが大切です。
作業８. パスワードポリシーの設定 [ MUST ]
パスワードポリシーを変更することで、IAMユーザーに設定するパスワードのルールを設定できます。 文字数、記号を含むなど、安全な条件を設定しておきます。
変更は、IAM＞アカウント設定から可能です。
サポートプラン
作業９. サポートプランの検討、変更 [ SHOULD ]
AWSには複数のサポートプランが用意されています。障害時やAWS内で事故があった場合は、AWSに迅速に対応してもらう必要もでてきます。基本的に本番環境で使用するAWSアカウントは、ビジネス以上のサポートプランに加入しておいたほうが良いでしょう。
サポートプランの変更は、ルートアカウントのみ実行可能です。
CloudTrail
CloudTrailにはAWS上の操作履歴が保存されます。デフォルトでは特に追加作業も不要で、90日間保存されCloudTrailの画面から確認することが可能です。
作業１０. CloudTrail証跡情報の作成 [ MUST ]
証跡情報を作成しS3に保存しておくことで、全ての操作履歴を残しておくことが可能です。比較的簡単に設定ができるため、必ず実施するようにしましょう。
（参考）CloudTrailの利用料金
CloudTrail自体の利用は無料で、証跡（S3保存）1つ目の料金は無料です。証跡は複数作成可能で、2個目以降の証跡は、データ保存分に対して料金が発生します。
AWS Config
作業１１. Configの有効化 [ MUST ]
AWS Config（以下、Config）を有効にすることで、AWSリソースの設定変更履歴を保存することができます。CloudTrailでは誰がどの操作を行ったのかという履歴を保存しますが、Configでは対象のAWSリソースがいつ、どのように変更されたのかという観点で履歴が保存されます。
以下の例では、セキュリティグループの設定履歴を表示しています。
作業１２. Config ルールの設定 [ BETTER ]
Configを有効にすることで、設定履歴を保存することができますが、それに加えConfigの機能であるConfig ルールを使用することで、AWSリソースが設定したルールに準拠しているかチェックすることが可能です。例えば以下のようなルールを設定してチェックを行うことができます。
- CloudTrailが有効になっているか
- S3バケットがパブリック読み書き可能になっていないか
- Security GroupでSSHポート（22）がパブリック公開されていないか
また、Config ルールと合わせて修復アクションを設定することで、SNS通知や自動修復処理も実装することが可能です。基本的にアカウント開設時はConfigを有効化するだけでOKですが、より厳しい運用が必要なAWSアカウントや、実装知識のある方はConfig ルールの運用も合わせて検討するようにしましょう。
（参考）Configの利用料金
記録された設定項目1件につき0.003USD発生します。例えば月あたり5000件の設定変更があった場合は$15の料金が発生します。 設定変更とは別にConfig ルールも1件の評価あたり0.001USD（～100,000 件）発生します。例えば1時間ごとに評価を行うルールが1件あった場合、0.001USD×24時間×31日＝0.744USDが月単位で発生することになります。
Amazon GuardDuty
Amazon GuardDuty(以下、GuardDuty)は、AWS上の悪意のある操作や不正な動作を検知するサービスです。例えば以下のような情報が検知されます。
- ルートユーザの使用
- IAMユーザーの不正利用(大量の操作実行など)
- EC2の不正通信
インプットとなる情報はCloudTrail、VPC Flow Logs、DNS Logsの３つで、そこから上記のような不正を判断して検知を行います。
作業１３. GuardDuty 有効化 [ MUST ]
GuardDutyのサービス画面から、有効化するのみで使用可能なため、アカウント開設後、すぐに設定するようにしましょう。
どのように検知されるか見たい場合は、サンプルイベントの発行も可能です。
作業１４. GuardDuty 通知設定 [ SHOULD ]
有効化にすることで、AWSマネジメントコンソールの画面から検知結果を確認できるようになりますが、これだけではリアルタイムに検知ができません。余裕のある方は、EventBridgeとSNSを使用して、管理者にメール等で通知を行う設定も合わせて行いましょう。
EventBridgeのサービス画面からルール＞ルールを作成を選択し、イベントソースにGuardDuty、GuardDuty Findingを選択すれば、右側のターゲットに検知結果を渡すことができます。ターゲットにメール通知を設定したSNSを選択することで、メール通知が可能です。（SNSトピックは事前に作成する必要があります。）
後述するSecurty HubでGuardDutyの通知も合わせて行う場合は、この設定は不要です。
（参考）GuardDutyの利用料金
CloudTrail（S3 データイベントも含む）、VPC Flow Logs、DNS Logsの利用量に応じて利用料金が発生します。 利用状況により異なるため一概には言えませんが、大規模なサービスを公開していない限りは、$10以下になると考えて良いでしょう。
※2022年1月にAmazon Elastic Kubernetes Service（EKS）も対象となり、こちらも料金の対象となっています。
Amazon GuardDuty now protects Amazon Elastic Kubernetes Service clusters Kubernetes protection in Amazon GuardDuty - Amazon GuardDuty
IAM Access Analyzer
作業１５. アナライザーの作成 [ MUST ]
IAM Access AnalyzerはIAMの画面からアナライザーを作成することで、AWSアカウント外と共有しているIAMロールやS3バケットなどのAWSリソースを一覧で確認することができます。マルチアカウントが一般的なっている中で、AWSアカウント間の連携も多くなってきました。意図しない外部への許可はセキュリティリスクとなるため、定期的に状況を確認しておく必要があります。
リージョン単位での設定が必要なため、利用するリージョン全てで設定する必要があります。
（参考）IAM Access Analyzerの利用料金
IAM Access Analyzerの利用料金は無料です。料金を気にされる方も積極的にアナライザーを作成しましょう。
AWS Security Hub
AWS Security Hub（以下、Security Hub）は、AWSアカウント内のセキュリティ状況やコンプライアンスの準拠状況を1箇所で確認できるサービスです。以下2種類の検出が可能です。
- CIS AWS Foundations BenchmarkやPCI DSSといった基準にしたがったコンプライアンスチェック
- GuardDuty、Macie、Inspector、Firewall Manager、IAM Access Analyzerといった各種AWSのセキュリティサービスや3rd Partyのセキュリティサービスの検出、アラートの一元管理
検出するサービスにGuardDutyやIAM Access Analyzerも含まれますが、Security Hubを有効にすることでこれらも自動的に有効化される訳ではないため、個別に有効化する必要があります。
作業１６. Security Hub 有効化 [ MUST ]
Security Hubのサービス画面で有効化するのみで使用が可能です。
作業１７. Security Hub 通知設定 [ BETTER ]
GuardDuty同様、リアルタイム検知を行う場合はEventBridgeによる検知設定を行います。ただし、Security Hubの結果を全て通知すると、通知量が多くなるため、必要に応じて以下のように通知する結果を限定的にします。
例1：結果の重要度がHIGH、MEDIUMのみ通知する
EventBridgeのサービス画面からルール＞ルールを作成を選択し、イベントパターンを編集し、以下の通り入力します。detail.findings.Severity.LabelをJSONで指定することで、指定した重要度のみの通知が可能です。
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "Severity": { "Label": [ "CRITICAL", "HIGH", "MEDIUM" ] } } } }
例2：GuardDutyの結果のみ通知する
イベントパターンを以下の通り入力します。
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "ProductFields": { "aws/securityhub/ProductName": [ "GuardDuty" ] } } } }
最初はリアルタイム通知を限定的にしておいて、自分のAWSアカウントの検知状況を定期的に確認しながら、リアルタイム通知すべき結果を整理していくようにしましょう。
（参考）Security Hubの利用料金
コンプライアンスチェックの件数と、各種サービスの検出結果の件数の件数に応じて料金が発生します。 検出結果は1万件までは無料のため、大規模な利用が無い限りは無料と考えて良いでしょう。コンプライアンスチェックは1チェックあたり0.0010USDが発生します。少しでも料金が気になる方はコンプライアンスチェックを無効化することも可能です。
Amazon Detective
Amazon Detective（以下、Detective）は、VPC Flow Logs、CloudTrail、GuardDuty などの他のAWSサービスの情報をインプットに、潜在的なセキュリティ問題や不信なアクティビティを分析、調査できるサービスです。
GuardDutyは発生したセキュリティイベントを検知するため、発生したイベントベースでの調査を行うことになりますが、Detectiveでは過去のログやイベント情報をといった時系列の観点を含み、グラフ等で視覚化することが可能です。GuardDutyとは目的が異なるため、両方共に有効にすることが大切です。
作業１８. Detective 有効化 [ SHOULD ]
Detectiveのサービス画面で有効化するのみで使用が可能です。
以下の画面はあるIAMユーザー1つを対象とした分析画面です。成功、失敗のAPI Call数（どれだけ操作を行ったのか）がグラフとして表示されています。
グラフの中から、Failed callsが多いグラフ部分をクリックすると、その時間帯に関する情報が合わせて表示されます。呼ばれたAPIの内容（失敗数、成功数含む）、実行元IPアドレス、使用されたアクセスキー情報を確認することができます。
こういった情報から、時間帯、実行量、実行内容といった観点で簡単に分析することができます。 今回はIAMユーザーを例に紹介しましたが、他にもEC2、AWSアカウント、IPアドレス、ユーザーエージェント、GuardDutyの検知イベントをベースとした分析も可能です。どの地域から実行されているかといった観点で確認も可能です。イベント検知後の調査に活用しましょう。
（参考）Detectiveの利用料金
GuardDutyと同様に取得した情報量により変動します。GuardDutyよりも料金は高めに設定されているため、GuardDutyの2～3倍に程度になると考えられます。30日間の無料トライアル期間がありますので、まずは利用してみて状況を見ると良いでしょう。
準拠法の変更
作業１９. AWS Artifactによる準拠法の変更 [ SHOULD ]
AWS アカウント開設時、準拠法は米国ワシントン州法となっていますが、準拠法を日本法に変更できます。 法的な手続きやトラブル発生時のことを考えると、日本で利用する場合は日本に変えておいたほうが良いでしょう。「日本法に準拠すること」というお客様の要件がある場合もあります。
変更はAWS Artifactの画面から可能で、契約＞「日本準拠法に関する～」をクリックし、契約をダウンロードして内容確認します。確認後、契約を受諾することで準拠法が変更されます。
まとめ
いかがでしたでしょうか。それなりの作業量があったかと思います。 AWSアカウント開設の都度、これらの作業を手動で実施するのは手間がかかるため、CloudFormationやTerraformといったサービスを使用してテンプレート化を行い、設定を自動化することも合わせて検討しましょう。
また、Organizationsが使える環境であれば、Control Towerや一括設定機能を使用して自動設定することも可能です。
こういったセキュリティ系のサービスは、日々アップデートが行われるため、最新情報をキャッチアップして、設定する作業内容も更新していくことが大切です。
AWSのセキュリティ支援もやっていますので、何かあればご相談ください！
