はじめに
AWS のセキュリティブログにクラウドのアカウントを守るためのヒントが紹介されていたのでメモとしてまとめておきます。
10 個のセキュリティアドバイス
AWS re:Invent 2019 では AWS の最高情報セキュリティ責任者である Stephen Schmidt 氏によって「the top 10 most important cloud security tips（クラウドセキュリティの最も重要なヒントトップ10）」が発表されたそうです。
そこでは次に示す 10 個に注意を払うべきだとされています。
- Accurate account info
- Use MFA
- No hard-coding secrets
- Limit security groups
- Intentional data policies
- Centralize AWS CloudTrail logs
- Validate IAM roles
- Take action on GuardDuty fidings
- Rotate your keys
- Being involved in dev cycle
AWS セキュリティブログでこれらのポイントがひとつずつ紹介されていたのでひとつずつ見ていこうと思います。
Accurate account info
アカウントの情報は常に最新かつ正確であることを心がけてくださいという注意です。
カスタマーの AWS アカウントに対して AWS から連絡を取る必要がある場合、AWS Management Console で定義された連絡先情報を使用しますが、これが正しく運用されていないと困った事態を引き起こす可能性があります。
たとえばメールアドレスが最新化されていないと AWS からのメールが届かない可能性があり、重要なお知らせを見逃すかもしれません。とくに abuse@amazon.com から送られてくるメールは AWS 不正使用対策チームからの連絡であり、カスタマーの AWS アカウントにセキュリティ的な問題がある可能性があります。このメールを見逃すと、最悪の場合アカウントの停止に追い込まれる可能性があります。
このような最悪の事態を防ぐためにも連絡先の最新化は重要ですし、自身の AWS リソースの不正利用に気づくためにも連絡先を最新化することが強く推奨されます。
AWS 不正使用対策チームが扱う不正行動（スパム、ポートスキャニングなど）については次のドキュメントが参考になりました。
参考：AWS 不正使用の報告
連絡先の更新方法については次のドキュメントが役に立ちます。
Use MFA
MFA（多要素認証）を使いなさいというお話です。
MFA はアカウントへの不正アクセスを防ぐ最良の手法と言われています。そのため、AWS のルートユーザーと IAM ユーザーには必ず MFA を設定することが推奨されています。
AWS の SSO（シングルサインオン）やフェデレーションサービスを使用する場合、IdP（アイデンティティプロバイダー）を使用する場合も MFA を強制すべきとされています。
AWS で MFA を有効にするには次のドキュメントが参考になります。
参考：AWS での多エレメント認証 (MFA) の使用 - AWS Identity and Access Management
No hard-coding secrets
当たり前ですが、資格情報をハードコードするな！というお話です。
そもそも AWS では AWS IAM ロールを使用して一時的な短命の資格情報を配信することができますが、アプリケーションやデータベースのパスワード、その他の API キーのように長命の資格情報が必要となる場合もあります。このような場合に、アプリケーションのソースコードに直接資格情報を書き込んではいけません。
AWS では AWS Secrets Manager というサービスが提供されています。これを使うことで、任意の資格情報をアプリケーションから API コールで取得できるようになります。そのため、アプリケーション内に資格情報を保存する必要がなくなります。
参考：AWS Secrets Manager（シークレットのローテーション、管理、取得）| AWS
その他、Amazon EC2 上で動作するアプリケーションに AWS の IAM ロールを使用したり、AWS Secrets Manager を使用して AWS Lambda にデータベースの認証情報を安全に提供する方法もあるそうです。
参考：Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する - AWS Identity and Access Management
なお、IAM ロールは起動時に EC2 インスタンスに割り当てることもできれば、すでに実行中の EC2 インスタンスに割り当てることもできるそうです。
アカウント／認証・認可まわりの知識が本当に不足しているのでどんどん学んでいきたいものです。
Limit security groups
これはオンプレミス時代と変わらない考え方ですね。適切なネットワークアクセス制御を有効にして必要なネットワークからの必要なポートへのアクセスだけを許可する構成としましょうというお話です。
AWS には環境内のネットワークアクセス制御が意図した状態になっているかを監視するために AWS Config や AWS Firewall Manager というサービスが用意されているそうです。
たとえばセキュリティグループの変更を監視したい場合は AWS Config を使用するか、AWS CloudTrail と Amazon CloudWatch Events を組み合わせて検知する方法があるそうです。
Intentional data policies
データを適切に分類する（公開/非公開や重要度で分ける）ことはセキュリティ上極めて重要とされ、この分類をもとにデータセキュリティ対策を設計するべきと説かれています。
もし、分類ポリシーが無い場合は公開データと非公開データをどう扱うかから考え始めることを推奨されています。
ここでは Amazon S3 を使う場合の実践方法が 3 つ紹介されていました。
- パブリック公開する S3 バケットがある場合はプライベートの S3 バケットがあるアカウントと分離すべき
- ポリシーを設定して人間ではなくプロセスのみがアクセス可能とすべき
- AWS Key Management Service (KMS）を使って暗号化と復号化に異なる IAM ロールを割り当てることで、データ入力（暗号化）とデータ参照（復号化）を明確に分離、そのロールを分析することで復号化に失敗した場合の脅威検知を行える
Centralize AWS CloudTrail logs
ロギングとモニタリングの重要性について説明されています。
AWS では AWS CloudTrail のログを S3 のバケットに書き込むことを推奨しています。S3 バケットのアクセスポリシーも厳格に管理し、ログの改変/削除ができないようにすべきです。また、暗号化も必要です。
ログを一元管理できていれば、必要に応じて SIEM ソリューションと連携して可視化したり分析することができます。もちろん、AWS のサービスを使った可視化方法も用意されているとのことです。
AWS CloudTrail が最優先ですが、CloudWatch Logs や Elastic Load Balancing などのリソースからログを収集して一元化しておくことも大切とのことです。
Validate IAM roles
不必要な IAM ロールは消しましょうというお話です。そのために、 AWS IAM Access Analyzer というツールが役に立つとされています。
個人的にはこの機能まったく知らなかったです…。
参考：AWS Identity & Access Management アクセス分析 - アマゾン ウェブ サービス
Take action on GuardDuty fidings
ブログ内では「Take actions on findings (This isn’t just GuardDuty anymore!)」と書かれていました。AWS Security Hub、Amazon GuardDuty、AWS Identity and Access Management Access Analyzer はいずれも AWS マネージドのサービスで、有効化するだけで AWS アカウント内のさまざまな調査結果を提供してくれます。また、複数の AWS アカウントを持っている場合は、結果を統合して管理することもできます。
まずはこれらの機能を有効化しましょう。そして、調査結果をもとに取るべきアクションを定義しましょう。つかいこなせばアクションを自動化することもできます。
Rotate your keys
長命の資格情報はセキュリティホールとなりやすいので、定期的にローテーションする必要があるということです。基本的には短命の IAM ロールを使うことが推奨されますが、できない場合は長命の資格情報（アクセスキー）を使う必要がありますが、この場合はアクセスキーを定期的にローテーションすることがベストプラクティスとなります。
AWS アクセスキーを管理するためのベストプラクティス を確認してみると、アクセスキーを持っていれば誰でも同じレベルの AWS リソースにアクセスできてしまうので、次のベストプラクティスを推奨しているようです。
- アカウントアクセスキーを削除する (または生成しない)
- 長期のアクセスキーの代わりに一時的なセキュリティ認証情報（IAM ロール）を使用する
- IAM ユーザーのアクセスキーを適切に管理する
- AWS アクセスキーを使用してモバイルアプリにアクセスする
Being involved in dev cycle
上記の 9 個のアドバイスはシステマティックなお話でしたが、10 個目のアドバイスである「Being involved in dev cycle」は「人」に焦点があたっています。これは「組織のセキュリティ文化を高める」ことが大事だよというお話です。
良いこと書いてあるなーと思ったのは「セキュリティはすべての人の仕事であり、肩書きにセキュリティを掲げている人だけの仕事ではありません」という一文。うちの会社のセキュリティ担当にも見せてやりたいですね。
セキュリティリーダーシップの育成については次の文書にまとまっているそうです。今度読んでみようと思います。
参考：ebook-cultivating-security-leadership.pdf
おわりに
AWS アカウントを守るためのセキュリティアドバイスを 10 個見てきました。技術的な観点としては AWS IAM を深く理解することは必須だなと感じました。わたしは認証・認可の分野がヨワヨワのエンジニアなので、なんとかここを補強していきたいと思います。
つくづく思うのは、AWS 真面目にやりだすとフルスタックエンジニアにならざるを得ないですね。がんばります。
以上
