LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック

メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

サービス・製品 | 

自組織のクラウド環境を点検してみませんか?~えっ...、ラックのAWS環境のアラート、多すぎ...?

クラウドインフラの規模は年々拡大しており、利用者も増加しています。とても便利でメリットが大きい一方、取り扱いには様々なリスクもあります。具体的にはどのような問題が潜んでいて、自組織はその問題に対応できているのでしょうか?

実際にラックの社内環境を分析してみましたので、その結果をご覧いただきたいと思います。ぜひご自身の組織の参考にしていただけると幸いです。

社内環境は安全に違いないって本当?

今、自分が利用しているクラウド環境は安全な状態ですか?それとも、安全に気を遣っている状態ですか?

この二つの問いは、似ているようで大きな違いがあります。極論を言ってしまえば、どれだけセキュリティを気にかけていても、インシデントが起きてしまうこともあります。

クラウドの隆盛に伴い、情報システムを準備する際のハードルは劇的に下がりました。クラウドならば、物理的な制約やデータセンターの準備、ラックの設計、電圧・配線・基幹スイッチなどの調整や作業員の手配、オペレーターや巡回監視員の管理などといった様々な手間を省いて、複数のサーバやネットワークを利用するインフラを用意できます。しかし、セキュリティ性と利便性はトレードオフであることも否めません。権限を持つユーザのうち誰か一人がミスをしてしまうと、その影響はインフラ全体に及ぶ危険性もあります。実際、クラウドにおけるセキュリティインシデントの主な原因は設定ミスと言われています。

※ ガートナーの調査では、その割合は2020年時点では95%を占め、2025年時点では99%を占めると予想されています。
October 10, 2019「Is the Cloud Secure?」
https://www.gartner.com/smarterwithgartner/is-the-cloud-secure

さて、もう一度初めの質問に戻りますが、本当に今のクラウドは安全ですか?安全に構築するためのルール設計までは行っている、しかしそのルールが適切か、過不足無く運用されているのか確認できていますか?

今一度、確認してみませんか?

社内のAWS環境を診断してみた

そもそもラックでは、Prisma Cloudという製品を用いたセキュリティ統制支援サービスを提供しています。そのため、社内に技術検証用のPrisma Cloud環境があります。当製品はクラウド上で稼働している資源数に応じてクレジットと呼ばれるものを消費する形態なのですが、ちょうど他の検証が終わりPrisma Cloudの検証用ライセンスが浮いたので、社内にある技術検証用AWS環境を診断してみようということになりました。

ラック社内の環境はきちんとルール整備されています。自分も、一時的なテスト用に作製したインスタンスがルール外だと叱られたり、攻撃検知テストとして発行したSQLインジェクションパケットが掴まえられてしこたま絞られたりした経験があるので、実際に診断してみても「キレイな環境だね」というオチだろうと高を括っていました。

Prisma Cloudの導入は簡単です。下記図の通り、Wizardに従いAWSにログインし、CFTを実行してしまえば完了します。

Prisma Cloudへのアカウント登録
Prisma Cloudへのアカウント登録

社内検証環境を繋いで、どれだけ設定不備が指摘されているのかを確認してみると......あれ?

Prisma Cloudでラックの社内検証環境を確認すると589件のアラートが上がっていた
検証環境で検知された問題がある設定

顕在化した問題は無かった。でも、リスクは潜伏していた

正直、驚きました。利用者の立場から見ていると、この環境はきちんと統制されているようにしか見えなかったからです。30~40程度のアラート出力数を見込んでいたのですが、結果は桁が一つ違いました。なら、どうするか。どんな対応をするにせよ、まずは現状を確認しないと始まりません。もしかしたら、常に定期的にあがるアラートがあるのかもしれません。しかし、それは都度解消されていて、実際には現存しているアラートはほぼ無いのかもしれない......。そんな思いを胸に、アラートの状態と発生日を確認してみた図が下記になります。

アラートのステータス
アラートのステータス
アラートの発生日
アラートの発生日

どうやら4月7日に検証環境が蹂躙されていますね。何処の誰が何をしたのか、まずは確認してみます。その際、Prisma Cloudを用いてアセットの情報と、そのアセット群がどんなアラートを発生させているのかを追いかけます。結果、根本的な原因でもあり、影響度大として検知されたアラートと資源群(の一部)が下記でした。インターネット上に直接開かれてしまっている仮想マシンが当該環境上に複数存在しているという......。統制外で作られてしまっているのならば由々しき事態です。

結果として、特定のユーザが問題の資源群を対象日に構築していたことが分かりました。ではどのような事情で構築していたのかを、作成者に確認していきます。

検知された危険な設定(一部)
検知された危険な設定(一部)

作成者にヒアリングしたところ、お客様環境にてSaaSサービスを構築する際に、いったん内部環境で技術検証を行おうとした際に作成した資源群だったとのことでした。例外申請といったフローも通していたとのことで、インシデントではなくほっとしました。また、申請を通した後に本当に一瞬だけ起動させて検証に使ったものだということで、現時点では停止中です。セキュリティホールとしては"生きて"いなかったということが分かり、まずは一安心です。

ですが、それで終わりかといえばそうではありません。管理フローに改善の余地がありますよね。利用が完了しているのに、アラートを発生させるインスタンスと関連リソース群が一月以上潜伏していたのですから。実際に、利用終了後に削除し忘れていたインスタンスを起因とした、セキュリティインシデントが発生したという事例もあります。それならば、特殊な申請で許可した資源は、期限切れと同時に削除するような仕組みを何かしら考えた方がいいという改善ポイントが見つかったわけです。

また、上記で8割がたのアラートを始末できたとはいえ、残りのものも無視はできません。勢いに乗って潰し込みを行ったところ、そのうち半分は社内環境の運用ルール変更により一時的に出力されたものだと確認できました。今まで前例がないオペレーションが実行されたというアラートが主だったのですが、こちらも出力された理由と影響を確認することに成功。見事、アラートを約600件から40件程度にまで抑え込むことができました。これなら当初の見込みともズレも少なく、また残存しているのはベストプラクティスに属する指摘のみです。つまり、自信をもって"安全"な状態のクラウド環境を利用できていると言えるようになったわけです。

運用ルール変更後、アラートの総数が37件まで減少した
対応後イメージ図

今一度、現状を"見える化"してみませんか

さて、ここで再度提案します。ご自身の組織の環境も、"見える化"してみませんか?

セキュリティは中々難しいですよね。インシデントが起きた時には問題視される一方、インシデントが起きなければセキュリティに関わる部門の人は何をしているのか分かりにくいように感じます。セキュリティは空気のようにあって当たり前、安全にシステムが運用されて当たり前と思われているのかもしれません。

見える化を行い現状の問題点を改善していくことで、セキュリティについて何が行われているのか、どうメリットが出たのかを分かりやすく示すことができます。その際は、ぜひラックのセキュリティ統制支援サービスPrisma Cloudも検討いただけると幸いです。クラウドプロバイダごとに、特色のあるCSPMサービスは提供されています。ただ、Prisma Cloudの場合は導入が容易で、導入後の機能改善やルールの最新化頻度が高く、長い目で見れば運用コストの面でも優れた製品です。セキュリティ統制支援サービスはPoCで触ってみると、よりメリットを実感していただきやすいのでおすすめです。さらに、現在無償でチェックを行うキャンペーンなども計画しています。

この機会に、今まで作り上げてきたセキュリティルールやプロセスがどれだけ有効に利用されているのか、紙面ではなく実際の設定状況から確認してみてください。問題点をキレイに解消できると、気持ちいいですよ。

関連記事

この記事は役に立ちましたか?

はい いいえ