当社では、クラウドプラットフォームの様々なリソースに対する設定がセキュアになっているかを診断する、「クラウドセキュリティ設定診断サービス」を提供しています。
診断には「AWS Security Hub」というAWSのサービスを使用しており、診断基準は「CIS Benchmark（※）」 に則っています。
※CIS Benchmark・・・米国の政府機関と企業や学術機関などのセキュリティエキスパートで構成される非営利団体「CIS（Center For Internet Security）」が発行している、システムを安全に構築・運用するためのベストプラクティスが記載されたガイドライン。準拠することで一定のセキュリティを提供する。
診断では、AWS Security Hubを有効にして自動的にチェックされるものに加え、CIS BenchmarkでAWS Security Hub自動チェックに対応していない項目を、診断員がクラウドプラットフォームにアクセスし、各リソースの設定を手動でチェックしています。
今回は、診断においてよく検出される項目についてご紹介します。
なお、これまでの実績ではどの案件でも全体の診断項目のうち、約6割に問題が見つかっています。やや高めに思えるかもしれませんが、まずは診断を受けてみる、という状態で実施しているところもあるかと思いますのでご了承ください。
AWS Security Hubの「重要度」について
重要度は、「重要」、「高」、「中」、「低」の4つに分類されています。「重要」が最も危険度が高く、直ちに修正が必要です。
重要度の定義
- 重要：この問題は、さらに悪化しないように直ちに修復する必要があります。
- 高：この問題は短期的な優先事項として対処する必要があります。
- 中：この問題は、中期的な優先事項として対処する必要があります。
- 低：この問題には、独自のアクションは必要ありません。
よく検出される項目（重要、高）
以下の3項目は、すべての診断において挙げられます。ただし、これらは「確認する」という項目であり、診断時点で運用上、正しい情報が設定されているかどうかを判断することができません。
そのため、診断結果としてこれらの項目には、「「運用時に正しいかどうか確認してください」と手順書を添えて報告しています。
| 1.1 | AWS アカウントの連絡先が最新であることを確認する |
|---|---|
| 1.7 | rootユーザーをAWSの管理／運用業務に使用していないことを確認する |
| 1.11 | IAM ユーザーの作成時にアクセスキーを設定していないことを確認する |
高頻度で検出されたものの中で、特に注意していただきたい項目は以下です。
| 5.4 | VPC のデフォルトセキュリティグループがすべてのトラフィックを制限することを確認する |
|---|
VPCのデフォルトセキュリティグループには、初期設定として特定のルールが適用されています。インバウンドトラフィックは、同じセキュリティグループに属するリソース間の通信がすべて許可されます。一方、アウトバウンドトラフィックは、すべての宛先への通信が許可されています。
たとえば、EC2インスタンスを起動する際に特定のセキュリティグループを指定しなかった場合、自動的にデフォルトセキュリティグループが適用され、この初期設定のルールが有効になります。この場合、インバウンドトラフィックとアウトバウンドトラフィックの許可範囲が広いため、意図しない通信が行われる可能性があり、セキュリティリスクが生じる恐れがあります。そのため、診断の報告時には、設定の変更を依頼しています。
よく検出される項目（中）
「中」では以下の項目が高頻度で検出されました。
| 1.8 | IAM パスワードポリシーで「最低 14 文字以上」の長さが必要であることを確認する |
|---|---|
| 1.10 | AWSマネジメントコンソールを通じたアクセスが有効化されているIAMユーザーに対してMFA(Multi-Factor Authentication-多要素認証)が有効になっていることを確認する |
| 1.12 | IAM ユーザーに対して 45 日以上使用されていない認証情報が存在しないことを確認する |
| 1.14 | アクセスキーが 90 日以内にローテーションされることを確認する |
| 1.18 | EC2インスタンスからAWSリソースにアクセスするために必要な最低限の権限を持つIAMロールが適用されていることを確認する |
| 3.3 | AWS Config が全てのリージョンで有効であることを確認する |
1.18では、IAMロールがアタッチされていればよい、という扱いにしていますが、逆にアタッチされていなかった場合が悩ましいところです。IAMロールがアタッチされていなければ、EC2インスタンスから他のAWSリソースにはアクセスできないため、問題ないと考える方もおられるかもしれません。確かに、権限がないのでアクセスはできませんし、AWSリソースにアクセスする想定がないのであれば、特に問題はありません。
ただし、IAMロールをアタッチしなくても、EC2インスタンスの中にIAMユーザーのアクセスキーやクレデンシャルを保存して、それを利用して他のAWSリソースにアクセスする、という使い方をされる場合があります。認証情報の漏洩リスクが高まるほか、認証情報の管理やトラッキングが困難になったり、過剰な権限を持つ可能性があるため、補足情報として注意喚起しています。
3.5では、AWS Configのベストプラクティスとしては、全アカウント、全リージョンで有効化することが推奨されています。CloudFormationで複数のリージョンで一括してAWS Configを有効にできますので、設定自体の負担は少ないと思います。ただ、テンプレートを使用すると、グローバルリソースの記録が全リージョンで有効化され、必要以上に課金される可能性があります。特定のリージョンのみグローバルリソースの記録を有効化する、といった設定が可能ですので、テンプレートの修正などを推奨しています。
よく検出される項目（低）
重要度「低」では以下の項目が高頻度で検出されました。
| 1.9 | IAM パスワードポリシーでパスワードの再使用を防止しているか確認する |
|---|---|
| 1.15 | IAM ユーザーがグループを通してパーミッションが付与されていることを確認する |
| 1.17 | IAM ロールにインシデントを管理するためのサポートロールが作成されていることを確認する |
| 2.1.3 | S3 バケット内の全てのデータが必要に応じて、自動的に発見・分類・保護されていることを確認する |
| 4.1 | 不正な API 呼び出しに対してログメトリックフィルタとアラームが設定されていることを確認する |
| 4.2 | MFA を使用しないコンソールサインインに対してログメトリックフィルタとアラームが存在することを確認する |
| 4.3 | rootユーザーの使用に対してログメトリックフィルタとアラームが存在することを確認する |
| 4.4 | IAM ポリシーの変更に対してログメトリックフィルタとアラームが存在することを確認する |
| 4.5 | CloudTrail の設定変更に対してログメトリックフィルタとアラームが存在することを確認する |
| 4.6 | AWSマネジメントコンソールの認証失敗に対してログメトリックフィルタとアラームが存在することを確認する |
| 4.7 | CMK の無効化または削除に対してログメトリックフィルタとアラームが存在することを確認する |
ここで特筆したいのは、 4.1～4.7までのロギングというカテゴリに分類されるものです。これらは、要はCloudTrailで記録されたログをCloudWatch Logsで通知されるように設定しているかどうかです。例えば、4.3では、通常の運用では使用しないことが推奨されているrootユーザーが使われた場合に、管理者に通知が届くよう設定されているかどうか、となります。
不正なログイン試行やポリシー変更、システムの異常やエラーの検知・通知の仕組みがなかったために、インシデントに気づくのが遅れたり、ログが取得できていないがために対応が遅れるケースをニュース等で見たことがある方も多いのではないでしょうか。
ログや通知が適切に設定されているかどうかは、脆弱性診断では検出されないことも多く、「低」とはいえ重要な項目として認識いただきたいと思います。
まとめ
今回は、これまでの診断で高頻度で検出される項目のなかで、特に気にしていただきたい内容について解説しました。
クラウドは自由度が高いことがメリットですが、その分設定が必要な項目が多く、運用にはそれなりの知識が必要です。クラウドをよく理解しないまま移行を進めた結果、設定ミスによるインシデントが急増しています。
KDLの診断では、診断結果とともに、リスクおよび対策手順書を提出しており、設定の修正までのアドバイスをさせていただいています。
設定に不安がある場合は、ぜひクラウド設定セキュリティ診断サービスをご検討ください。診断が必要かどうかまずは相談してみたい、という方もお気軽にお問い合わせください。
