AWS スペシャリストが教える、すぐにするべきセキュリティ対策

みなさんが AWS 環境を利用する際、1 つの IAM ユーザーを複数人で使いまわしたり、root ユーザーを利用したりしていないでしょうか ? ここのポイントは「誰が何をしたかわかるようにしておく」です。

IAM ユーザーを共有していると、なにか問題が起こった時の原因追跡が難しくなります。 「EC2 インスタンスがいつのまにかシャットダウンしていたけど、これは誰がやったの ? 」というケースですね。ログには admin という IAM ユーザーが操作したと記録されているが、この admin は結局だれだろう ? という感じです。

AWS 環境を操作する人間やプログラムに対して 1:1 に対応したユーザー (アイデンティティ) を作成しておくことで、「誰が何をしたか」をログから追跡することができます。また、アイデンティティを正しく分けておくことで、退職者の ID など使われていないアイデンティティを管理やすくなりますし、「EC2 の操作は運用チームのメンバーのみ作業可」といったアクセス権の管理も行いやすくなります。

root ユーザーの共有も NG です。どんな操作も実行できる強力なユーザーですので、日常の操作では利用しないことを強く推奨しています。Multi-factor Authentication (MFA) を設定してトークンを安全な場所に保管しておきましょう。また補足ですが、普段使いの IAM ユーザーもできるだけ MFA を利用して多要素認証を行ってください。というのも、パスワードによる認証だけではすでにセキュリティの確保が難しい情勢となっています。MFA は物理的なトークンの他、スマートフォンにインストールする仮想 MFA など、低コストで導入できるものもあります。詳しくはこちら を参照ください。

また、アプリケーションから他の AWS リソースへアクセスさせる場合も、IAM ロールが利用できないかまず検討してみてください。IAM ロールを使うことで固定のアクセスキーを作成せず、一時的な認証情報を都度取得してアクセスさせることが簡単に実現できます。

もちろん、オンプレミスのサーバーからのアクセスなど、AWS 外部からの接続でアクセスキーがどうしても必要になる場合もあります。この場合は複数のサーバーで共有せず、一定期間でアクセスキーをローテーションさせる運用にしてください。そうすることで、知らない間にアクセスキーが漏れた場合でも、その認証情報を使ってアクセスされる期間を制限することができます。

「誰が何をしたかわかるようにしておく」とお話しましたが、ログを記録している前提でお伝えしていました。順番が前後しましたが、その情報の元となるログはきちんと取っておきましょう。

AWS アカウント作成時に設定いただきたいサービスが 2 つあります。AWS CloudTrail と AWS Config です。CloudTrail はユーザーの振る舞いと API 操作のアクティビティを記録するもので「誰が、いつ、どんな AWS操作を行ったか」を記録します。特に設定を行わなくても、標準で 90 日間のログが記録されますが、それ以前のログを確認したいケースがよく起こります。設定手順は CloudTrail チュートリアル - 最初の証跡の作成 をご参照ください。

また、Config は AWS リソースの構成情報を継続的に記録するサービスです。AWS リソースの依存関係も扱うことができるので、例えば「この EC2 インスタンスに付与されていたセキュリティグループはどれで、その時はどんな内容だった ?」といった確認を簡単に行うことができます。設定手順は こちら をご参照ください。

この図に挙げたように、ポートスキャンからインスタンス、アカウントへの脅威などに対して検知を行います。

たとえば、EC2 インスタンスがマルウェアに感染し C&C サーバーと通信が発生している場合や、不正に API が呼び出され EC2 インスタンスが大量に起動し、暗号通貨の採掘を行われている場合などにもアラートを通知します。

こういった脅威への対策としては、適切なアクセス制御など、基本的なセキュリティ対策ができていることが大前提です。さらにその上で、万が一問題が起こった時に備え、数日後に急増した料金などで気が付くのではなく、すぐに不審な動作を検知できる体制にしておくとセキュリティの成熟度をより高めることができます。

GuardDuty は 1 クリックで有効化でき、AWS 上で稼働するワークロードへの影響もなく、30 日間の無料トライアルで効果やコストを測定することができます。利用したことがなければぜひ試してみてください。

最後の項目は、実は一番みなさんにお伝えしたい内容です。「アプリケーションが動作するための権限を、できる限り必要最小にしておく」というものです。

この最小権限を考える場合、誰が検討すると適切で簡単に設定できるでしょうか ? たとえば「この Lambda 関数はどの S3 バケットにアクセスするのか、SQS キューは読み込みだけか ?」などの質問にすぐ答えられる人は・・・そう、アプリケーションの仕様を分かっている人ですよね。つまり、builder のみなさんこそ、アクセス権限を最適に設定できるのです。

アプリケーションを開発する時、面倒だからといって Administrator Access で設定することは避けてください。アクセスキー漏洩時のリスクが大きくなってしまいます。最小権限の設定のために、まず対象となるリソースをしっかり絞り込んで、その上で許可するアクションを定義していきます。S3FullAccess などの「サービス名 + FullAccess」 よりさらに踏み込んで、読み込み / 書き込みなどを絞り込んで IAM ポリシーを定義できないか意識すると、より最小権限に近づくことができます。

一例として AWS Serverless Application Model (SAM) を利用した際の TIPS をご紹介します。SAM は CloudFormation の拡張機能で、簡潔で直感的にサーバレスアプリケーションを定義できる特徴があります。この SAM の定義の中では、アプリケーションに与える権限についても簡単に記述できるようになっています。

SAMテンプレート (template.yaml) でのアクセスポリシー定義

上記は 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 をより便利に、そして安全に使っていただけることを願っております。