AWSのセキュリティリスクを可視化し、クラウド全体のセキュリティを向上させる

この記事はクラウドのセキュリティリスクを可視化して、リスクを低減する、顧客の安全を向上させる記事です。

課題

Webサービスを運用していると、モグラたたきのように個別のクラウドリスクには対応できても、全体のクラウドリスクを把握して、対応していくということが難しいです。

セキュリティ専任が採用されるまでは、インフラ/SREがセキュリティの役割を兼任していることが多いです。しかし、彼らは本来の業務で忙しいです。よって、セキュリティエンジニアがいない場合、なにかあってから対応するということが多いです。

そのようなよくある課題に対して、クラウド全体のセキュリティリスクを可視化する。そして対策をしていくことでプロダクト価値を向上させていきます。結果として、顧客は安全にサービスを受けることができます。

セキュリティリスクを可視化するには理想の状態と現状のギャップから生まれます。

そしてその理想の状態は世の中で使用されているCISなどのセキュリティガイドラインが望ましいです。よって今回はそのようなセキュリティガイドラインとのギャップを抽出してくれるツールを使っていきます。

ツールはいくつか存在しますが、今回はよく使われていて、シンプルに使えるprowlerを使います。

[blogcard url=”https://github.com/prowler-cloud/prowler”]

使い方は簡単です。AWSの認証情報を設定し、prowlerを実行するだけです。

prowler aws -f ap-northeast-1

可視化できたので、あとはセキュリティ対策を行っています。

しかし、ここで少し待ってください。よくあるダメなケースについて説明します。多くの人はゼロリスクを目指して、Failedとなっているすべてに対処しようとします。

これはものすごく効率が悪いです。考え方次第ですが、リスクが高くない場合は許容する、つまり対処しないということも選択肢に入れます。

今回の場合だと、シンプルに判断するなら、CriticalとHighのみ対処して、それ以外はいったん許容するという判断です。時間があるなら、1つ1つ内容を精査して、許容するかどうか判断しても良いでしょう。ここは今あるリソースと相談です。

1つ確認してみましょう。同時に生成されたHTMLファイルを開き、CriticalとHighでフィルタリングをかけます。

見てみると、S3のパブリックアクセスブロックが有効になっていないという内容です。これを運用と照らし合わせて、どのように変更するのか考えていきます。

上記で対策ができたあと、これで終わりで良いでしょうか？

もう1歩踏み込んで考えていくなら、AWS Security HubとAWS configを使って継続的に設定を監視していったり、また今回のクラウドセキュリティテストも1回やって終わりではなく、継続的にやっていくのが良いでしょう。

理由は2つあります。

つまり、今回のようなクラウドセキュリティテストで定期的にクラウド全体を確認し、個別の設定変更の監視にはAWS Security HubとAWS configを使っていく、という運用です。

今回のような課題に対して、このような継続的なセキュリティ施策を用いることで開発スピードを落とすことなく、顧客の安全を向上させることができます。