AWS スペシャリストが教える、すぐにするべきセキュリティ対策
桐谷 彰一
builders.flash 読者のみなさん こんにちは ! セキュリティ スペシャリストソリューションアーキテクトの桐谷です。
みなさん、セキュリティに気をつけていますか ? セキュリティと聞くとつい面倒だなと思ってしまう方、いらっしゃると思います。「どんなに素晴らしいサービスを開発しても、セキュリティに問題あると価値は一気に下がってしまう」とセキュリティの重要性はわかっていても、どこまで対策したらよいのか悩んでいる方もおられるかもしれません。
実際、AWS アカウントを作成した際に何をすればいいのか、AWS のセキュリティサービスは何を使えばいいのか、そういったお問合せを定期的にいただいています。
このような疑問に対して、「AWS アカウントのセキュリティを改善するための 10 個の項目」等でご案内していますが、今回は、builders のみなさんに「ココに気を付けてほしい !」というセキュリティ対策をまとめてみたいと思います。
「アイデンティティとアクセス管理」、「ログ管理・脅威検知」、「アプリケーションの最小権限」の 3 つのカテゴリでご紹介します。みなさんの AWS 環境が今どうなっているか思い浮かべながら、ぜひ読み進めてください。
このシリーズ記事のその他の記事はこちら
- 選択
- ビルダーのビルダーによるビルダーのためのセキュリティ »
- セキュリティを何から始めれば良いか分からない開発者の方へ »
- DevSecOps パイプラインを構築してみよう ! »
- Amazon Inspector と AWS Systems Manager を用いて脆弱性の修復パイプラインを構築しよう
- マルチテナント SaaS アプリケーションの認証を Amazon Cognito で実現してみよう !
- すぐに始めて、継続できる AWS のセキュリティ対策
1. アイデンティティとアクセス管理
みなさんが AWS 環境を利用する際、1 つの IAM ユーザーを複数人で使いまわしたり、root ユーザーを利用したりしていないでしょうか ? ここのポイントは「誰が何をしたかわかるようにしておく」です。
IAM ユーザーを共有していると、なにか問題が起こった時の原因追跡が難しくなります。 「EC2 インスタンスがいつのまにかシャットダウンしていたけど、これは誰がやったの ? 」というケースですね。ログには admin という IAM ユーザーが操作したと記録されているが、この admin は結局だれだろう ? という感じです。
AWS 環境を操作する人間やプログラムに対して 1:1 に対応したユーザー (アイデンティティ) を作成しておくことで、「誰が何をしたか」をログから追跡することができます。また、アイデンティティを正しく分けておくことで、退職者の ID など使われていないアイデンティティを管理やすくなりますし、「EC2 の操作は運用チームのメンバーのみ作業可」といったアクセス権の管理も行いやすくなります。
実現方法としては、ユーザー毎に IAM ユーザーを用意してもいいですし、こちらの図のように AWS Single Sign-On (SSO) を利用して、社内外の ID 基盤 (ActiveDirectory や Azure AD, G suite など) と連携して、既存のアカウント情報と統合することもできます。 (既存の ID 基盤がない場合も、AWS SSO の中に ID 情報を登録して管理することもできます)
(図) AWS SSO を利用した AWS へのアクセスとアイデンティティ管理
root ユーザーの共有も NG です。どんな操作も実行できる強力なユーザーですので、日常の操作では利用しないことを強く推奨しています。Multi-factor Authentication (MFA) を設定してトークンを安全な場所に保管しておきましょう。また補足ですが、普段使いの IAM ユーザーもできるだけ MFA を利用して多要素認証を行ってください。というのも、パスワードによる認証だけではすでにセキュリティの確保が難しい情勢となっています。MFA は物理的なトークンの他、スマートフォンにインストールする仮想 MFA など、低コストで導入できるものもあります。詳しくはこちら を参照ください。
アクセスキーのとりまわし
アクセスキーも AWS リソースへのアクセス権をもつ認証情報の 1 つで、注意して管理する必要があります。ここのポイントは、「できる限り使わない。使っても一時的なものにするか、定期的にローテーションさせる」です。
builder のみなさんは、開発環境で AWS のアクセスキーを利用するケースがあると思います。つい固定のアクセスキーを作成して開発環境に埋め込んで使いたくなりますが、できるだけ一時的な認証情報を利用するようにしましょう。
たとえば AWS CLI v2 であれば、AWS SSO を使って認証して、一時的な認証情報をローカルの開発環境に取り込むことができます。先ほどのアイデンティ管理とあわせて SSO の活用を検討してください。
(図) AWS CLIv2 での SSO ログオン
また、アプリケーションから他の AWS リソースへアクセスさせる場合も、IAM ロールが利用できないかまず検討してみてください。IAM ロールを使うことで固定のアクセスキーを作成せず、一時的な認証情報を都度取得してアクセスさせることが簡単に実現できます。
もちろん、オンプレミスのサーバーからのアクセスなど、AWS 外部からの接続でアクセスキーがどうしても必要になる場合もあります。この場合は複数のサーバーで共有せず、一定期間でアクセスキーをローテーションさせる運用にしてください。そうすることで、知らない間にアクセスキーが漏れた場合でも、その認証情報を使ってアクセスされる期間を制限することができます。
2. ログ管理・脅威検知
ログの保存
「誰が何をしたかわかるようにしておく」とお話しましたが、ログを記録している前提でお伝えしていました。順番が前後しましたが、その情報の元となるログはきちんと取っておきましょう。
AWS アカウント作成時に設定いただきたいサービスが 2 つあります。AWS CloudTrail と AWS Config です。CloudTrail はユーザーの振る舞いと API 操作のアクティビティを記録するもので「誰が、いつ、どんな AWS操作を行ったか」を記録します。特に設定を行わなくても、標準で 90 日間のログが記録されますが、それ以前のログを確認したいケースがよく起こります。設定手順は CloudTrail チュートリアル - 最初の証跡の作成 をご参照ください。
また、Config は AWS リソースの構成情報を継続的に記録するサービスです。AWS リソースの依存関係も扱うことができるので、例えば「この EC2 インスタンスに付与されていたセキュリティグループはどれで、その時はどんな内容だった ?」といった確認を簡単に行うことができます。設定手順は こちら をご参照ください。
脅威検知
ログの保存と同時に、そのログを監視しセキュリティの脅威を検知できる体制を整えておくことをお勧めしています。AWS では Amazon GuardDuty という脅威検知のマネージドサービスがあります。先ほど紹介した CloudTrail などのログを監視し、不審な動作が検知されたきに管理者に通知することができます。
(図) Amazon GuardDuty
この図に挙げたように、ポートスキャンからインスタンス、アカウントへの脅威などに対して検知を行います。
たとえば、EC2 インスタンスがマルウェアに感染し C&C サーバーと通信が発生している場合や、不正に API が呼び出され EC2 インスタンスが大量に起動し、暗号通貨の採掘を行われている場合などにもアラートを通知します。
こういった脅威への対策としては、適切なアクセス制御など、基本的なセキュリティ対策ができていることが大前提です。さらにその上で、万が一問題が起こった時に備え、数日後に急増した料金などで気が付くのではなく、すぐに不審な動作を検知できる体制にしておくとセキュリティの成熟度をより高めることができます。
GuardDuty は 1 クリックで有効化でき、AWS 上で稼働するワークロードへの影響もなく、30 日間の無料トライアルで効果やコストを測定することができます。利用したことがなければぜひ試してみてください。
3. アプリケーションの最小権限
最後の項目は、実は一番みなさんにお伝えしたい内容です。「アプリケーションが動作するための権限を、できる限り必要最小にしておく」というものです。
この最小権限を考える場合、誰が検討すると適切で簡単に設定できるでしょうか ? たとえば「この Lambda 関数はどの S3 バケットにアクセスするのか、SQS キューは読み込みだけか ?」などの質問にすぐ答えられる人は・・・そう、アプリケーションの仕様を分かっている人ですよね。つまり、builder のみなさんこそ、アクセス権限を最適に設定できるのです。
アプリケーションを開発する時、面倒だからといって Administrator Access で設定することは避けてください。アクセスキー漏洩時のリスクが大きくなってしまいます。最小権限の設定のために、まず対象となるリソースをしっかり絞り込んで、その上で許可するアクションを定義していきます。S3FullAccess などの「サービス名 + FullAccess」 よりさらに踏み込んで、読み込み / 書き込みなどを絞り込んで IAM ポリシーを定義できないか意識すると、より最小権限に近づくことができます。
一例として AWS Serverless Application Model (SAM) を利用した際の TIPS をご紹介します。SAM は CloudFormation の拡張機能で、簡潔で直感的にサーバレスアプリケーションを定義できる特徴があります。この SAM の定義の中では、アプリケーションに与える権限についても簡単に記述できるようになっています。
SAMテンプレート (template.yaml) でのアクセスポリシー定義
MyFunction:
Type: 'AWS::Serverless::Function'
Properties:
CodeUri: ${codeuri}
Handler: hello.handler
Runtime: python2.7
Policies:
- SQSPollerPolicy:
QueueName:
!GetAtt MyQueue.QueueName
上記は Lambda 関数を定義している部分です。この中の Policies 句で SQSPollerPolicy があり、さらに QueueName が指定されていることに注目してください。SQS にポーリングを許可するポリシーテンプレートに併せて、ポーリング対象の SQS キューの情報が定義されています。つまり、この SAM によって作成された Lambda 関数は、同じく作成された SQS キューに対してのみポーリングができるような IAM ポリシーが作成、付与されるようになっています。
このように SAM でサーバレスアプリケーションを構成していくと同時に、アクセス権限も同時に定義していくことができます。この権限の設計スタイルはとても効果的です。他にもよく使われるアクセス権限はポリシーテンプレートとして用意されています。 詳しく SAM デベロッパーガイド: AWS SAM ポリシーテンプレート を参照ください。
まとめ
以上、builder のみなさんに気を付けてほしいセキュリティ対策のポイントをご紹介しました。
3 つのカテゴリとして
- 「アイデンティティとアクセス管理」
- 「ログ管理・脅威検知」
- 「アプリケーションの最小権限」
をお伝えしましたが、みなさんがご利用中の AWS 環境ではどうだったでしょうか ? もし対策できていない部分があれば・・・この記事に出会ったのがよい機会です。ぜひ後回しにせず、対策の計画をたてていただければ幸いです。
本日ご紹介した内容の設定の流れを確認したい方は、以下の AWS Hands-on for Beginners でも一部紹介しています。ぜひご参考にしてください。
- “アカウント作成後すぐやるセキュリティ対策” 編を公開しました!- Monthly AWS Hands-on for Beginners 2020年4月号"
- AWS Hands-on for Beginners: Security #1 アカウント作成後すぐやるセキュリティ対策
みなさんに AWS をより便利に、そして安全に使っていただけることを願っております。
このシリーズ記事のその他の記事はこちら
- 選択
- ビルダーのビルダーによるビルダーのためのセキュリティ »
- セキュリティを何から始めれば良いか分からない開発者の方へ »
- DevSecOps パイプラインを構築してみよう ! »
- Amazon Inspector と AWS Systems Manager を用いて脆弱性の修復パイプラインを構築しよう
- マルチテナント SaaS アプリケーションの認証を Amazon Cognito で実現してみよう !
- すぐに始めて、継続できる AWS のセキュリティ対策
プロフィール
桐谷 彰一 (きりたに しょういち)
アマゾン ウェブ サービス ジャパン合同会社
セキュリティ ソリューションアーキテクト
AWS 入社前はセキュリティベンダー、ネットワークベンダーのプリセールスエンジニアとして、エンタープライズ、官公庁のお客様のセキュリティ対策のご支援を行っていました。好きな AWS サービスは GuardDuty と Security Hub。好きな和菓子は鹿の子。趣味は日本酒を飲みながら打つ囲碁 (弱い) です。
AWS を無料でお試しいただけます