🛡️

クラウドセキュリティ診断プラットフォーム「Cloudbase」を使ったらリスクがいっぱい検出されたので直してみた

2022/03/07に公開

AWS

Cloudbaseとは

クラウドのセキュリティ事故の原因は、2025年になると設定ミスが99%になると予測されているそうです。
Cloudbaseは事故につながる設定ミスを「お手軽に」スキャンできるサービスです。
執筆時はAWS向けのβ版がリリースされています。

動機

普段使っているAWSアカウントがどのようなセキュリティリスクをどれくらい抱えているのかは気になりますが、今まで計測したことはありませんでした。
一度全体像を見るだけでも今後のセキュリティ意識が変わると思い、今回はCloudbaseを用いてチェックするとともに、実際に危険度の高いリスクを直してみました。

導入方法

Cloudbaseのアカウントに、スキャンを行うAWSアカウントのIAMを登録するのみです。
IAMの作り方や必要な権限はマニュアルが用意されており、導入のサポートも受けられるので、普段あまりIAMを触っていない人でも簡単に導入できると思います。
自分はIAMを触り慣れていたのもあり、ものの数分で設定が完了しました。

適切な権限を持つIAMを作って登録するだけ

スキャン結果

プライベートで使っているアカウントに対してスキャンをしてみました。
vpcがいくつか、ec2がいくつかみたいな簡単な開発環境があるくらいで、そんなにたくさんのリソースはないのですが、それでもかなりのリスクが検出されて驚きました。
実際にサービスの運用をしているようなアカウントだとどれくらい検出されるのか見ものですね。

トップページ
最新のスキャン結果の概要が表示される

詳細画面で全てのリスクを確認できる

EC2はインスタンスだけでなくVPC等様々なサービスを含むので、一番多く検出されています。
EC2を抜くと、認証や権限に関わるIAMが一番多いです。
気になる項目を見ていくとともに、危険度がCRITICALのものを取り除いていこうと思います。

S3バケットのパブリックアクセスのブロック

1つ目

詳細画面では各項目のリソースと、リスクになっている原因を確認することができます。

どうやらs3のパブリックアクセスが許可されています。

バケット名から自動で作られたものっぽいので調べてみたところ（既にある程度名前から推測できますが）、AWS SAM CLIのsam deployコマンドの際に自動で作られるバケットのようです。
2020年頃にSAMを少し触ったことがあり、その時のものが残っていました。
なぜパプリックで作られているのかは謎ですが、今は使っていないので消すことにしました。
最新のCLIのバージョンではちゃんとプライベートで作られるようになっているかもしれません（未検証）。

普通に見えているオブジェクトを全部消してからバケットを消そうとしたら、まだオブジェクトが残っているので消せませんと出てきました。
前にも同じようなことがあり、さてはこいつバージョニングが有効になっているな？と思い確認したら当たりでした、そこはしっかりしているんですね。
バージョニングされたオブジェクトも削除すると、無事バケットが削除できました。

2つ目

CloudTrailのログ用のバケットもパプリックになっていました。
こちらも2020年頃に作成しており、おそらくCloudTrailの作成画面で名前だけ入力し、あとは自動で作成されたバケットだと思われます。
パプリックである必要性は全くもってないので、「パブリックアクセスをすべてブロック」をオンにしました。

執筆時に新しくCloudTrail経由で作成されたバケットを確認したところ、デフォルトで「パブリックアクセスをすべてブロック」はオンになっていました。
AWSのデフォルトのセキュリティも完璧ではなく、日々アップデートされているようです。
自動で作られたリソースがセキュリティリスクを抱えているのは少し怖いですね（後で他の例としてSSHのポート開放も出てきます）。

使用中のルートアカウント

ルートアカウントでログインしないようにしましょうというものです。
アカウント作成直後にすべきこととして、IAMユーザーを作成してそちらでログインするようにする、があると思います。

IAMのダッシュボード画面でも推奨される

筆者ももちろん過去にIAMユーザーは作っており、普段はそちらを使うようにしていたのですが、今使っているPCにcredentialの情報を共有しておらず、面倒臭がってルートアカウントでログインしています。
よくないですね(・ω<) ﾃﾍﾍﾟﾛ

普段からルートアカウントを使っていないのにこのリスクが検出された場合、かなり怪しい＆危ないのですぐに調べたほうが良さそうです。

利用を終了したアクセスキー

アクセスキーは90日以下でローテーションすることが公式で推奨されています。

ローカル環境でAWS CLIを叩く際に使っているアクセスキーは古いものは削除し、新しいものを発行しました。
使っていないアクセスキーは削除しました。

また、基本的にAWS内のサービス同士のアクセスにはIAMユーザーは使わず、IAMロールを使いましょう。

SSHのポート開放

調べてみると、SSHのポートに対してソースが全開放されていました。

セキュリティグループの説明にlaunch-wizard-1 createdという記述があり、これを調べてみると、launch-wizard-{number}はEC2の作成過程でセキュリティグループを新規作成する際のデフォルト名であることがわかりました。
これに関するリスクが危険度はLOWですが別で検出されていました。

EC2の作成手順を1個ずつ進むと、ステップ6でセキュリティグループの設定ができるのですが、ここのソースのデフォルト値が全開放になっています。

また「確認と作成」ボタンを押して手順をスキップした場合も同様に全開放の設定となります。

結論、何かの検証用に適当なEC2インスタンスが欲しく、その際に脳死で作ったセキュリティグループのようでした。
対応としてはソースを自分のIPのみに設定しました。

何かしらの認証があれば基本大丈夫だと思いますが、ない場合は知らない間に入り込まれる可能性が大いにありそうです。

安全でないEC2インスタンスメタデータオプション

このリスクに関しては全然わからなかったので調べたところ、以下の記事が見つかりました。

詳細は省きますが、EC2インスタンスのメタデータを用いてSSRFができるみたいです。
対応として、インスタンスのメタデータのオプションで

HttpTokensを有効にするとメタデータのリクエストにトークンが必須となる
HttpEndpointを無効にするとメタデータを提供しなくなる

の少なくとも一方を設定することで、メタデータへのアクセスのセキュリティを高めることができるようです。

全く知らなかったので勉強になりました。

再スキャン結果

設定の変更によって対応できる危険度がCRITICALのものを全て取り除くことができました。

感想

セキュリティリスクは対応する必要はあるものの、どこを対応すればいいかわからないことも多いので、今どのレベルのリスクがどれだけあるかを簡単に確認できるのは非常に良かったです。
自動で作成されるリソースやデフォルト値にセキュリティリスクを含むものが多々あることがわかったのも良かったです。

IaCでリソース管理する機会も増えてきていますが、ちょっとした検証環境とかは手動で作ることも多々あり、またそれらのセキュリティは本番環境ほどは気にせずに作る場合も多く、さらに消し忘れることも多いです。
そういったリソースも含めてスキャン結果に出てくるので、適切に対応を行えば、セキュリティリスクだけでなく、請求コストや管理コストも削減にも繋がりそうだと思いました。

まだAWSのみのβ版なので、これからのアップデートに期待です。