[まとめ] AWSのアクセスキーを安全に管理する方法

はじめに
- AWS アクセスキー
- アクセスキーの漏洩
立場に応じた責任
- AWSアカウント管理者の責任
- 開発者の責任
追記

はじめに

この記事では、「AWSアクセスキーが漏洩するのをどうやって防ぐか」「アクセスキーをどうやって管理すべきか」についてまとめてあります。AWSのリファレンスをベースに、アカウント管理者視点と開発者視点に分けて記載しました。

AWS アクセスキー

AWSにプログラムでアクセスするときに必要となるのが、AWSのアクセスキーです。

IAMを作成して、アクセスキーを発行すると以下のようにAccess Key IDとSecret access keyを発行することができ、IAMがもっているポリシーに従って、AWSにアクセスすることができます。

このアクセスキーで誰でもAWSにアクセスすることができます。

つまり、あなたがこのアクセスキー情報をブログに貼って、全世界に公開したら、それを見た人は、そのキーで、あなたのAWSアカウントにアクセスできるというわけです（もちろん画像のアクセスキーは削除済みです）。

アクセスキーの漏洩

実はこのアクセスキーの漏洩事故は多いのです。 GitHubにアクセスキーを誤って公開してしまい、それをハッカーに検知され、EC2インスタンスを作られまくったり、DDoS攻撃の踏み台にされたりということが起こっています。もちろん請求はあなた持ちです。

AWSが不正利用され300万円の請求が届いてから免除までの一部始終 - Qiita

GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！ - Qiita

初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita

This Is What Happened When I Leaked My AWS Secret Key | Alexander Paterson

以上のように日本にとどまらず、世界中でやらかしています。個人でやっているアカウントならまだしも、もし企業の本番環境用のアカウントで漏洩したら、倒産するかもしれません。S3やRDSなどのストレージを全部抜かれて、「返して欲しければ」って脅されて…考えたくないですね。

今回は、どうやってこのような事故を防ぐかについてまとめてみました。

立場に応じた責任

ベースとなる情報はAWSのリファレンスを参照しています。きちんとAWSもベストプラクティスを出していますので、初めてアクセスキーを利用する前には一読しましょう。

docs.aws.amazon.com

企業でAWSを運用していると、相当数の開発者が絡んできます。全員にきちんと教育をして実践してもらうのは、非常に難しいはずです。ですので本記事ではAWSアカウント管理者としての責任と、イチ開発者としての責任に分けて説明します。

AWSアカウント管理者の責任

まずはアカウント管理者の立場でみてみましょう。ここでいうアカウント管理者はIAMの登録権限をもっている人です。企業でAWSを運用する場合には、通常アカウントの管理者をたてています。その人がルートアカウントの権限を持って、必要に応じて開発者にIAMの発行をしたりしています。

ルートアカウントのAWSアクセスキーを発行しない

これは大原則です。ルートアカウントで発行されたキーは、全てのことができます。アカウントをまるごと乗っ取ることができます。個人だとやらかしやすいので、気をつけましょう。IAMの説明をスキップした初学者向けチュートリアルは危険です。チュートリアルの完成記念にGitHubに上げてしまい事故るという未来が容易に想像できます。

AWS アカウントのルートユーザー - AWS Identity and Access Management

AWS アカウントのルートユーザーのアクセスキー (アクセスキー ID とシークレットアクセスキー) は、作成、更新、無効化、または削除できます。ルートユーザーパスワードを変更することもできます。AWS アカウントのルートユーザー認証情報を持っていればだれでも、請求情報を含むアカウントのすべてのリソースに無制限にアクセスできます。

最小権限のポリシーでアクセスキーを発行する

IAMはポリシーに紐付いています。ポリシーは「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」かを制御するものです。アクセスキーを発行する際は、用途を最小限まで限定させましょう。万が一漏れても、操作を制限することができます。

自動検知

これはアカウント管理者の責任というより、会社としての責任かもしれません。
自社で管理するGitHubやGitLabなどのGitレポジトリに対して、アクセスキーが埋め込まれていないかどうかを自動検知するのが有効です。
アクセスキーのプレフィックスは「AKIA」から始まります。これでリポジトリの検索を定期的にかけましょう。

IAM ID - AWS Identity and Access Management

可能な限り送信元IPアドレスを絞る

可能な限り、送信元IPアドレスを絞りましょう。たとえアクセスキーが漏れたとしても指定外のIPからはアクセスできなくなるので、万が一漏れたとしても強力に働いてくれます。

AWS: 送信元 IP に基づいて AWS へのアクセスを拒否する - AWS Identity and Access Management

未利用のアクセスキーの削除

利用されていないアクセスキーは削除しましょう。AWSコンソールから最後に利用した日から何日経過されているかを確認できます。定期的にチェックして削除したり、もしくはAPIを利用して削除自体を自動化するなどして、ちゃんと活きているアクセスキーのみを残しましょう。

使用していない認証情報の検索 - AWS Identity and Access Management

AWS CloudTrailの利用

万が一漏れていたとしても、これで漏れたアクセスキーの利用履歴を追うことが出来ます。これによって今後の対応が変わります。過去90日間までのログでしたら無料で検索できます。

AWS CloudTrail (AWS API の呼び出し記録とログファイル送信） | AWS

利用者への教育

IAMやポリシーなど権限周りの教育は必ずしましょう。また、用途を聞いて認証情報をどう利用・管理するかも相談に乗りましょう。アクセスキーを発行しなくても済むケースも多々あるかと思います。

請求アラートを設定する

AWSの請求金額をモニタリングしてアラートをかけることができます。AWSアカウントを作成したら、アラートはかけておきましょう。不意の高額請求に早めに気づくことができます。

アラートと通知で請求額をモニタリング - AWS 請求情報とコスト管理

開発者の責任

イチ開発者がどこまでAWSを触っているかは企業や、チームの運用サービスによりけりだと思います。少人数で開発している場合ですと、イチ開発者でもAWSコンソールにログインして、色々することもあるかと思います。一方で大規模で開発していると、イチ開発者がAWSコンソールにログインすることは少ないのではないでしょうか。必要に応じて、管理者に申請してIAMやアクセスキーを発行していもらっているかと思います。その場合であっても、最低限の責任は伴います。