この記事について
NTTドコモテクニカルジャーナル Vol.29 No.1 "パブリッククラウドの利用に特化したセキュリティチェックツールの開発" の筆者による解説記事です。
AWS上で起こるセキュリティ事故
AWSの東京リージョンのリリースが2011年3月2日ですので、2021年で丸10年が経過したことになります。（ちなみに、この10年の節目である2021年3月2日に日本で二番目のリージョンである大阪リージョンが正式にGAとなったのは有名な話ですね。）
昨今、AWSをはじめとするパブリッククラウド上で企業がシステムを構築することはもはや当たり前になってきました。それにあわせて、AWS上で企業が顧客情報など特に機密性の高い情報を扱うようになってきていますが、当然ながらその際にはセキュリティが非常に重要となります。
セキュリティ対策がうまくできていないと、大規模な情報流出やサービスの停止などの重大なインシデントが発生してしまうかもしれません。特に大規模な事例として、米国Capital One社のシステムから1億人以上の個人情報が流出した事故を記憶している方も多いのではないでしょうか。
こういった事故は、AWSを利用していなかったら発生しなかった、と言えるかもしれません。しかしながら、ビジネスを大きく加速させることができるなど、パブリッククラウドを利用することのメリットが数多いことも事実であり、日本でもこれだけ企業でのクラウド利用が進んでいることがそれを物語っていると思います。もはや2021年現在において、セキュリティだけを理由にしてパブリッククラウドを利用しないという選択肢を取るのは、企業経営的にも適切ではないと考えられるかもしれません。
クラウドでのセキュリティ対策の考え方
パブリッククラウドを使う上で、まず理解しておきたい概念が「責任共有モデル」です。
例えばAWSでEC2を使う場合、AWSが主にデータセンタなどの物理的なファシリティから、物理マシンやネットワークなどのハードウェア、ホストOSや仮想化レイヤの管理までを実施する一方で、ゲストOSやその上で動作するアプリケーションは利用者側が責任をもって管理を行う必要があります。一方で、マネージドサービス（Lambdaなど）を利用すれば、利用者側が責任を負う範囲がより狭くなり、多くの管理をAWSに任せる事が可能となります。
このように、サービスごとにクラウド事業者とその利用者がそれぞれ責任を負う範囲を明確化して分担し，協力して対策を行っていくという考え方が責任共有モデルです。この時、クラウド事業者側がいくら対策を実施していたとしても、利用者側の設定次第では非常に危険な状態を作り出してしまう可能性があるというのを、強く認識しておく必要があります。
その上で、利用者側が責任を負う範囲をより狭くすることで、多くの管理をクラウド事業者側に任せる事が可能となり、その分付加価値の高いアプリケーションやビジネス領域に集中して企業のリソースを投下することができるというわけです。
クラウドの設定状況をチェックする
「利用者側の設定次第では非常に危険な状態を作り出してしまう可能性がある」というのをどうやって防止すれば良いでしょうか。そもそも危険な状態にならないようにAWSがやってくれるのが一番良いですよね。それを実現するための方法の1つがマネージドサービスを使うことなのですが、ではなぜ利用者側にも裁量が残されているかというと、それはもちろんビジネス要件に応じてシステムを作らなければならないからです。つまり、機械的に危険な設定を防止するという仕組みではうまくワークしないということを意味しています。
では、どのように対策をするのが良いのでしょうか。少なくとも、危険な状態となっている可能性が高い設定というのは抽出できそうです。
わかりやすい例では、「AWSのルートユーザーにMFAが設定されていない状態」というのは、AWSを利用していく上ではかなり危険な状態であり、アンチパターンとされています。そして、AWSがこの状態を完全に防止していないのには、MFAを設定されていない状態にあえてする必要性があるユースケースを考慮している（＋歴史的な経緯でそうせざるを得ない）のではないかと考えられます。例えば、検証用でAWSアカウントを一度に大量に管理する必要があるケースなどでしょうか（筆者の個人的な考えでは、いかなる場合でもルートユーザにはMFAを設定すべきと思います）。
そして、こういったケースでは最終的には利用者側で危険度を判断し、対処する必要が出てきます。つまり、
- 予期せず危険な状態になっているので、対策をする。
- 想定内なので、リスクを受容して期間な状態で使い続ける。
のどちらかを選択することになります。
アセスメントツール「ScanMonster」
セキュリティリスクの可視化と判断をするには、AWSを使う上でのアンチパターンがどのようなものか、それがどれくらい危険なのかを1つ1つ確認していかなければなりません。しかし、AWSを使う全員がAWSのエキスパートではないし、複数のリージョンやアカウントにまたがってたくさんのリソースを網羅的に確認していくのはAWSのエキスパートでも心が折れる作業ですよね。
そこで、セキュリティアセスメントを自動で行うことのできるツール「ScanMonster」を作りました。
- 複数のAWSアカウントに対して横断的にチェックが可能
- チェック結果を一目で確認可能
- AWS初心者にもわかりやすいチュートリアルを完備
ScanMonsterでは、これらの特徴で素早く自動的にAWS環境のチェックが可能です。そして、AWSのエキスパートでなくても、チュートリアルを読みながらリスクの把握とアクションの判断を行うことが可能です。
ScanMonsterのアーキテクチャ
ScanMonsterは、それ自体をAWS上に立てることにしました。そして、CloudFormationによるIaC化、AWS Lambdaを中心としたフルサーバーレス構成としています。
IaC化により、インフラまで全てがコードで管理されています。開発時には環境構築やテストの時間を短縮することができています。また、丸ごとScanMonsterを別のAWSアカウントに作って、別のチームで使うといったこともできるようになっています。
サーバーレスアーキテクチャを採用したことで、アセスメント実行時以外はほとんど費用の発生を抑えることができています。実際にScanMonsterでは毎月数百円ほどのランニングコストしか発生しておらず、EC2を1台だけ常時起動しているよりも安く抑えることができています。また、この記事中でもあったようにインフラの大部分の管理をAWS側がやってくれるマネージドサービスであるため、その分利用者側で意識しなければいけない責任範囲を少なくすることができています。
皆さんも、AWS上でツールを作成する際には、ぜひIaC・サーバーレスあたりをキーワードに設計してみてはいかがでしょうか。
そして、AWS上でセキュアにシステムを構築・運用していくためのツールは世の中にたくさんあります。AWSからもConfigやSecurity Hubのように同じようなことを実現できるサービスが提供されています。文中でも触れましたが、クラウドセキュリティはツールを入れたら終わりではありません。セキュリティリスクを正確に判断できるように、継続的にクラウドのことを勉強する必要もあります。
日々クラウドに関する知識のアップデートを怠らず、そして、ツールを賢く活用して、一緒に安全なクラウドライフを送っていきましょう。