年度末なので認証情報レポートを使用して不要な認証情報を探してみる

こんにちは!エンジニアの君島です。

 

年度末ですね。こういうタイミングでやっておいた方がいいことがあります。そう、管理しているAWSリソースの見直しです。

以前はIPPEIさんがコストの観点で記事を書いていました。

今回は、AWSのセキュリティに関する記事を書きたいと思います。

昨今、セキュリティ事故や悪意のある第三者からの攻撃も多く報告されています。先日も IPA(独立行政法人情報処理推進機構)から「情報セキュリティ10大脅威 2022」の解説資料が公開されました。こちらの資料は、2021年に発生した社会的に影響が大きかったと考えられる脅威を分かりやすく解説してくれていますので、是非ご一読ください。

少し脱線しましたが、こうした風潮だけではなく、社内でもセキュリティに関する要望が高まっているのを日々感じています。

 

IAMのベストプラクティスとは

IAMのベストプラクティスは公式ドキュメントでまとまっています。

こちらに書いてあることは必ずしも全ての環境で当てはまるものではないですが、先人たちが既に通ってきた道です。きちんと見て学んでおきましょう。

今回はAWSのベストプラクティスの中から、不要な認証情報の削除について、焦点を当ててみましょう。

 

不要な認証情報の発生のメカニズムと分析

不要な認証情報はなぜ発生するのか?

ここでの認証情報とは、IAM ユーザーのパスワードとアクセスキーを指しています。そもそもベストプラクティスにもあるように、アクセスキーの利用は望ましくありません。しかしながら、アクセスキーを利用せざるを得ない場合もあるでしょう。

 

それでは、どのような場合に不要な認証情報が残るかを考えてみました。概ね以下のようなケースが考えられるのではないでしょうか?

・社員の異動や退職によって使用しなくなったユーザーが残っている

・一時的に案件やサンドボックス上で利用していたユーザーやアクセスキーが残っている

・よくわからないでユーザーやアクセスキーを作成して、そのまま残っている

 

どれもよろしくはないです。中でも3番目はよろしくないですが、消さずに残っているということは特に3番目のようなケースが実は多いのではないでしょうか。

 

なぜ認証情報を削除すべきなのか?

パスワードやアクセスキーは長期的な認証情報です。アクセスキーであれば、キーとシークレットの情報のペアがあれば、長期的に認証情報を常に使用し続けることができます。一見便利に感じられるかもしれませんが、これらの情報が流出してしまった場合には、第三者がマネジメントコンソールに自由にログインしてIAMユーザーと同じ権限で操作できると想像してください。かなり、深刻な事態であることがよくわかると思います。

それでは、本題に入りましょう。実際に不要な認証情報があるかの棚卸と対策を行っていきます。

 

不要な認証情報を探して対策してみよう

認証情報レポートの出力

取得方法は非常に簡単です。マネジメントコンソールから操作します。

IAM > 認証情報レポート > レポートをダウンロードの順に操作すれば、csv形式でレポートがダウンロードできます。

 

取得した認証情報レポートの見方と対策

使用していないパスワード

”password_last_used”カラムが”no_information”になっていたり、一定以上に古くなっているユーザーはパスワードを一定以上使用していないユーザーと言えます。これらのユーザーについては、本当に必要なユーザーなのか確認してよいかもしれません。なお、”N/A”となっている場合には、パスワード自体が無効化されているユーザーですので、アクセスキーの有無で確認をするようにしましょう。

 

そのユーザーがマネジメントコンソールへのアクセスが不要だと判断ができたら、まずはコンソールアクセスを無効化しても良いかもしれません。ただし、パスワードを無効化しても、アクセスキーが残っていれば、そのキーはまだ有効です。アクセスキーについては以下で確認していきましょう。

 

使用していないアクセスキー

認証情報レポートの中に2つのアクセスキーについての情報があります。

アクセスキーのアクティブ状態(”access_key_1_active”と”access_key_2_active”、以降1つ目のキーのみ記載します。)、最後に作成、または変更した日時(”access_key_1_last_rotated”)、最後に使用した日時(”access_key_1_last_used_date”)、アクセスキーのリージョン(”access_key_1_last_used_region”)、およびサービス(”access_key_1_last_used_service”)といった情報を読み取ることができます。

 

”access_key_1_last_used_date”カラムを見て、最近使用していないアクセスキーがあれば、本当に使用していないか、何に使われているか確認の上、いきなり削除せずに、まずは無効化から始めてみましょう。

 

公式ドキュメントに書いてあるのは以上のパターンなのですが、もう少し掘り下げて見てみます。

IAMのベストプラクティスから振り返ってみましょう。

 

AWS アカウント ルートユーザーのアクセスキーをロックする

ルートユーザーは認証情報レポートの最初の行に出力されていると思います。

ルートユーザーのアクセスキーにより、請求情報を含む、すべての AWS サービスのお客様のリソースすべてにフルアクセスできますので、もしアクセスキーが有効されていたら削除するようにしましょう。

また、アクセスキーに限らず、ルートユーザーは基本的に使用すべきユーザーではないので、MFAも有効化すべきですし、頻繁にログインされていたりするようでしたら注意が必要です。

 

MFA の有効化

セキュリティのベストプラクティスにはIAMユーザーのMFA有効化があります。MFAを有効化しているかどうかは、”mfa_active”カラムを確認しましょう。TRUEになっていれば、有効化されています。MFAを有効化することで、パスワードが侵害されても追加の認証要件が必要となりますので、より安全になると言えます。

とはいえ、アクセスキーを使用しているようなプログラムの場合には、一時的な認証を取得するような改修が必要となるので、強制的な有効化は少し待った方が良いと思います。

 

ユーザーのために強度の高いパスワードポリシーを設定する

AWS のデフォルトのパスワードポリシーからアップグレードして、強力なパスワードかつ定期的なアップデートを要求するようにしているのが望ましいです。この点は、AWSに限りませんね。

認証情報レポートから、パスワードポリシーを完全に読み取ることはできません。ですが、パスワードの更新状況は理解できます。”password_next_rotation”カラムがあるので、パスワードの次回更新予定日時がわかります。パスワードが有効化されているのに、この値が”N/A”となっていた場合は、パスワードポリシーを定めていない可能性が高いので見直しておきましょう。

 

認証情報を定期的にローテーションする

繰り返しますが、アクセスキーは長期的な認証情報です。パスワード同様に定期的にローテーションしていきましょう。IAMユーザーごとに2つのアクティブな認証情報を持つことができます。これは、新たに認証情報を作成した時に新旧の認証情報を一時的に共存させておき、問題がないことが確認できてから古い認証情報を削除するという運用を行うためです。

”access_key_1_last_rotated”カラムと”access_key_2_last_rotated”カラムを確認して、時間が経っているようであれば、ローテーションをお勧めします。

また、そもそも2つのアクセスキーがアクティブであるのは、本来はローテーション中のものに限ります。”access_key_1_last_used_date”カラムと”access_key_2_last_used_date”カラムを確認して、どちらも最近利用されている場合は、2つのアクセスキーをアクティブに使用しているので、その運用は見直しましょう。

 

ロールを使用してアクセス許可を委任する

ここまでIAMユーザーやアクセスキーについて確認していきましたが、最後にもう一度こちらを確認しましょう。本当にその認証情報は必要でしょうか?

有効期間が限られているIAMロールでの一時的な認証を利用できる余地はないかというのは必ず検討してください。多少認証タスクが変わるかもしれませんが、長期的な認証情報を使用し続けるための管理や運用監視のコストや流出のリスクを抱え続けることと比べると、長期的な認証情報の使用は極力避けることをお勧めします。

 

まとめ

セキュリティの観点でIAMユーザーに焦点を当てて、使用していない認証情報の洗い出しと対策について記載しました。マネジメントコンソール上のIAMユーザー一覧で確認していたよという方は、是非認証情報レポートを使用してみてください。

 

宣伝

 

ギークフィードではAWSエンジニアを募集しています。

技術力に自信がある方も、一緒にAWSを利用したサービスを開発したい、AWS上でのセキュリティに詳しくなりたいという方も募集しています。

興味がある方はこちらからエントリーをお願いします!

AWS・開発エンジニア募集

この記事が気に入ったら
いいね ! しよう

Twitter で
The following two tabs change content below.
君島翔
君島翔
AI事業部事業部長株式会社ギークフィード
Java, .NET系の言語が得意。Laravelも使います。 エディタはvim派。 自分が楽するためにテストやビルド、デプロイを自動化させたい。 2022-2023 AWS Ambassador / 2022-2023 Japan AWS Top Engineer / 2022-2023 Japan AWS ALL Certifications Engineer

【採用情報】一緒に働く仲間を募集しています

採用情報
ページトップへ