セキュリティリスクへの対策
システムエンジニアにとってシステムのセキュリティ対策は必ず付いて回る課題です。システムの脆弱性を突かれた攻撃や不正アクセスによって情報漏洩でも発生すれば、企業には致命傷にもなりえる大損害を発生させることになります。システム開発のフローにおいても、システムの用途や重要度などから、セキュリティ対策にどれだけのコストをかけて堅牢性を担保するかはあらかじめ計画に織り込んでスケジュールが立てられていると思います。
気を付けるべきは運用環境だけなのか
一方で、実際のサービス運用をしているわけではないテスト環境やサンドボックス環境に対しては皆さんどれくらいの注意を払っていますでしょうか。
重要な顧客情報や業務情報がやり取りされる本番環境に対しては細心の注意とセキュリティの担保を考えると思いますが、ダミーデータしかないテスト環境やシステムの実装コードすら置いていないサンドボックス環境のセキュリティリスクを気にしたことはありますでしょうか。これらの環境は、例えば悪意のある第三者によって不正アクセスされたところで奪われるものは何もないし、検証用の環境にわざわざコストをかけてセキュリティ対策をするなど面倒すぎると思う人もいるかもしれません。一昔前のオンプレミスが主流のシステム開発であればその通りでしたが、AWSのようなクラウドサービスにおいては危険な考え方になります。
どうでもいいAWS環境に不正アクセスされてしまうとどうなるのか
それでは、ダミーデータしかないテスト環境やサンドボックス環境という、システム開発者からすれば「わりとどうでもいい環境」が悪意のある人間に不正アクセスされてしまうと何が起こるのか。具体的な過去の事例をいくつかあげておきます。
-
AWSアカウントがハッキングされて1日で500万円の請求が来た話(2021年Gigazineの記事)
- AWSのアカウントをハッキングされて暗号資産のマイニングに環境を使われた結果、1日で4万5000ドルのAWS利用金額の請求が来たという例
-
事例分析：AWS アクセスキーの漏洩による事故(Cloud Security Magazine)
- 漏洩したアクセスキーで不正アクセスされ、AWSの環境をマイニングに使われてしまった例
-
AWSが不正利用され300万円の請求が届いてから免除までの一部始終(2017年Qiita記事)
- Gitリポジトリ上のソースにハードコーディングしていたアクセスキーを使ってAWSを不正利用されて高額請求が来てしまった例
このような話は「AWS 不正利用 事例」などで検索すればたくさん出てきます。
これらのセキュリティインシデントに共通するのは、不正アクセスされた環境の重要性は関係なく、悪意のある人間にAWSへ不正アクセスされた結果、マイニングなどの用途でハイスペックのEC2インスタンスなどを大量生成・利用されて好き放題に環境を使われた結果、その利用コストを押し付けられてしまったということです。
なので、あなたにとってはちょっとしたお試しのためのサンドボックス環境として作ったAWSアカウントであっても、不正アクセスできる穴が開いていれば、悪意のある人間にとっては無制限利用をして高額請求を押し付ける格好のチャンスになるわけです。
どうやって不正アクセスをされるのか
アクセスキーの流出
AWSの不正アクセスで一番多いのがこれかと思われます。ローカルからAWS CLIを使ってAWSリソースに操作をしたい場合に、自分のIAMユーザーにアクセスキーを設定して利用している人もいると思います。もちろん注意を払って漏洩しないようにちゃんと管理できていればいいのですが、誤ってアクセスキー情報をパブリックな場所に書き込んでしまう、アクセスキー情報がハードコーディングされたソースコードをGithubのPublicリポジトリにPushしてしまう、などといったことでセキュリティ事故が起きてしまうケースがあります。
特にサンドボックス環境であれば、わざわざIAMユーザーの権限を厳密に管理などせずAdministrator権限で使用してしまっているかと思います。
個人の学習用のGithubリポジトリなどであれば、仮に誤ってアクセスキーをpublicリポジトリにアップしてしまったところで誰も見てなどいないだろうと思うかもしれません。しかし世の中にはそんな警戒心の薄い人を狙う悪い人たちが結構いるらしく、Githubなどでアクセスキーを検索するBOTが常時稼働しているそうです。
どうやって気を付ければいいのか
ではどうすればいいのかという話です。
案①：アクセスキーを使用しない
一番簡単にして確実な対策です。そもそもがアクセスキーの利用自体がセキュリティリスクにつながりやすい行為であり、特別な理由がない限りは不用意に利用するべきではありません。
アクセスキーを使用する一番の理由はAWS CLIかと思いますが、ローカルからアクセスキーで認証してAWS CLIを使わずとも、AWS CloudShellでAWSコンソールからアクセスして利用することも可能です。
参考：AWS CloudShell
案②：MFA(多要素認証)を強制する
それでも何かしらの理由でローカルからAWS CLIを使えないと困るんだ！という人は、IAMユーザーにMFAを設定してIAMポリシーでMFAを必須にしましょう。仮にアクセスキーを漏洩しても不正アクセスは防げます。
AWS CLIからだとIAMポリシーでMFAを必須にしないとMFAなしでもアクセスキーは使えてしまうので注意してください。
参考： IAM ユーザーの MFA を有効化した後、アクセスキーを使用する既存処理に影響があるか教えてください(クラスメソッド Developers IO)
案③：漏洩を事前に検知する
git-secretsという、Gitへのコミット内容をチェックして登録パターンに合致する内容があればコミットを防止する仕組みがあるので、これを取り入れてアクセスキーのうっかりアップロードを未然に防ぐこともできます。
参考： git-secretsを使用してAWSアクセスキーのコミットを防ぐ方法の紹介(クラスメソッド Developers IO)
ただしこれはGitへのアップロードを防ぐだけなので、SNSやどこか他の場所に流出させてしまったらどうにもなりません。
案④：不正アクセスを検知できるようにする
不正アクセスされないことが一番ですが、もしもの時の対策として、AWSにはAmazon GuardDutyという不正アクセスの発生を検出するサービスもあります。セキュリティの観点からもAmazon GuardDutyの利用は検討してみてもよいでしょう。
参考： Amazon GuardDuty
まとめ
必要がなければアクセスキーはなるべく有効にしないことが推奨となります。
AWS CLIでの操作が必要になるなど、どうしても必要な場合には上記の通りMFA必須にするなど、環境が運用環境だろうが個人のサンドボックス環境だろうが関係なく、取り扱いは厳重にするべきです。
セキュリティ意識が薄くなりがちな個人環境だからこそ、うっかりのやらかしに注意が必要です。