はじめに
とあるプロダクトの開発・運用しているのだが、ローンチが落ち着いて運用段階に入ってしばらく経った頃、セキュリティ大丈夫？という話が上がった。
もちろんサービスの設計・実装はセキュアになるように気をつけてはいるし、ローンチ前や定期的には外部の業者に脆弱性診断をしてもらっている。
ただ、考慮できてないリスクや、運用が進むにつれて生まれたリスクがもあると思われたので、改めてプロダクトのセキュリティについて調べていくことになった。
どう調べる？
私自身はセキュリティについて深い知識があるわけでもなく、今回の調査は雲を掴む話だったので、セキュリティ専門のエンジニアに相談した。
また自身でも次のようなサイトや書籍を読んで調査の方向性を探った。
IPAの情報セキュリティ対策サイト → アプリケーション開発でもよくお世話になったサイト。どう調査するのかの足がかりになった。
徹底攻略 情報処理安全確保支援士教科書 → 資格を取るわけではないが網羅的な知識を得られそうだったので読んでみた。期待通りだった。
やったこと
簡単にいうと、セキュリティのリスク評価を行った。
具体的には、次のようなステップで現状を調査した。
- システム全体の構成図の整理
- AWS Well-Architected セキュリティ評価
- 脅威の洗い出しとリスク評価
- 情報資産の洗い出しとリスク評価
実際は各ステップで色々と相談させてもらったり、試行錯誤していて、最初から全体像は見えていなかった。
それぞれ簡単に説明してみる。
システム全体の構成図の整理
セキュリティの現状を知る前に、まずはシステムの概要をだれでも把握できるように、システム構成図を一箇所にまとめた。
ツールには draw.io を使ったが、miroのような書きやすいツールでも良かったかもしれない。
多人数で作成したプロダクトだったのと、マイクロサービスに分かれていたこともあって、全体像を把握している人が少ない状況だった。さらに、それぞれ担当したマイクロサービスの設計資料はあったが、統一されたフォーマットでまとまっておらず、把握が難しい状況だった。
まとめたことによって、チーム外のセキュリティ専門エンジニアやインフラエンジニアにもプロダクトについて説明しやすくなったのと、新しくチームに加わる人へのオンボーディングも簡単になったのではないと思う。
ただメンテする資料が増えたことになるので、この資料を最新に保ち続けるのは工夫が必要である。
AWS Well-Architected セキュリティ評価
AWS Well-Architected Tool による、セキュリティ評価を行った。 （※ この記事のSaaSプロダクトは AWS を使って稼働しています。）
AWSからの質問に答えていくと、高リスクが◯件、中リスクが◯件、といったリスクの評価結果がでて、各リスクに対する推奨改善方法を教えてくれる。
セキュリティについてのベストプラクティスや、AWSからの推奨実装方法を知ることができるので、結構おすすめできる。
実施した結果、かなりの部分は自社が共通で導入している仕組みやツールで守られていることがわかった。
ただ改善点ももちろんあって、例えば以下の項目の対応が必要そうだった。
- 緊急アクセスのプロセスを確立する
- アクセス許可を継続的に削減する
脅威の洗い出しとリスク評価
「セキュリティ大丈夫？」という質問に答えるために、セキュリティのリスク評価を行うことになった。
まずは、短時間で大きなセキュリティリスクを見つけるに、脅威ベースのリスク評価を行った。
次のような流れでリスクを評価した。
- セキュリティ専門エンジニアとプロダクトのメンバーを集めて、ブレスト形式で脅威を洗い出す。(例えばサーバが乗っ取らるとか、不正利用など）
- プロダクトのメンバーで、脅威の発生頻度(大・中・小）と、脅威の影響の大きさ（大・中・小) を決める。
- 「脅威の発生頻度 x 発生したときの被害」でリスク値を決める
リスク評価前にぼんやりと、ここ危ないよなーと思っていたところがリスク値としてはっきり表現された印象があった。
:::message リスク評価方法について
リスク評価には、おおきく２つ方法があるそうだ。
- 脅威ベース（脅威を洗い出してから、それぞれについてリスク評価)
- 情報資産ベース（情報資産を洗い出してから、それぞれについてリスク評価)
（これは私の理解で、本当はもっと専門的な深い話だと思うが、ざっくりとこのように理解した。）
短時間で大きなリスクを見つけるには、脅威ベースのリスク評価が良いだろうという話になった。 :::
情報資産の洗い出しとリスク評価
情報資産ベースのリスク評価も行った。
このリスク評価では、何より情報資産を洗い出せたのが良かった。 内部監査では、この資料を参考にできるので短時間で回答できる。
IPAが用意してくれている リスク分析シート があるのでこれをベースにして、下のようにカスタマイズした。
- Google スプレッドシートにしてオンラインで確認、修正できるようにした
- 「脅威の状況」はSaaSやクラウドサービスにあうように内容を変更した
- 「情報資産のライフサイクル」というシートも追加して、情報資産ごとのライフサイクルも記録するようにした
調査としては次のようなステップになる
情報資産の調査
- 情報資産を洗い出す
- 情報資産の「機密性」を評価する
- 情報資産が個人情報であれば、個人情報の種類を決める（特定個人情報とか）
- 情報資産のライフサイクルを調べて、通過媒体や保存先を洗い出す
- 媒体・保存先ごとに情報資産を並べて、それぞれ「完全性」「可用性」を評価する
- 上記で評価した情報を元に、媒体・保存先ごとの情報資産の「重要度」が自動計算される
媒体・保存先の調査
- 情報資産の媒体や保存先を洗い出す
- 媒体・保存先ごとに脅威を洗い出す
- 媒体・保存先の脅威ごとに「被害発生の可能性」を評価する
リスク値の決定
リスク値=媒体・保存先ごとの情報資産の「重要度」x媒体・保存先の「被害発生の可能性」
運用
運用については特に改善の余地があるが、やったことをまとめてみる。
運用の整備
情報資産やリスク評価は、定期的に棚卸しして再評価しないといけないのだが、 理想としては、運用する中で順次更新されていってほしい。
理想に近づけるために、システムに新規機能を追加したときには、情報資産管理台帳もあわせて更新するようなルールを作った。
ただ漏れや既存機能などで新たに情報資産が増えることもあるので、定期的な棚卸しは必要かもしれない。
インシデント対応フローの整備
インシデント対応フローを整備して、重大なインシデントがあったときは、経営陣や社内のCSIRTチームにエスカレーションすることを、対応フローの中で明示した。
また、古くなっていた各種の連絡先も更新した。連絡先の更新も悩みのタネで、ほっておくと古くなってしまうので、定期的な棚卸しが必要になっている。
利用ソフトウェアのバージョン一覧表
利用しているソフトウェアを洗い出して、バージョン一覧表を作成した。
バージョン一覧表では、各ソフトウェアについて
- 利用バージョン
- 推奨バージョン
- 将来の予定（いつEOLを迎えるのか、など）
- ソフトウェアの利用箇所
をまとめている。
既存ソフトウェアに脆弱性が見つかったときは、すぐに現状や利用箇所の当たりがつくので、その点は改善された。ただ手動で運用が必要なので運用面が課題だ。
ロードマップ作成
リスク低減にむけての改善は、長期的で戦略的な仕事になるので、ロードマップを作成して改善方向性をチームメンバーで共有できるようにした。
まとめ
最初は漠然としたイメージだった「プロダクトのセキュリティ大丈夫？」という質問にも、最終的には情報資産の洗い出しとリスク評価を行うことで、ある程度回答できるようになったと思う。
また、情報資産とリスク評価を最新に保つために運用フローを整備したり、リスクが実現してインシデントが発生したときのために対応フローを整備したりと、運用の改善もおこなった。
ただ、課題も色々ある。
- 手動で更新している資料が多く、システムでの自動化ができていない（できない？）ので、更新が大変
- 手動更新が必要なので、チームメンバーに同じ温度感をもって対応を続けてもらわないといけないが、負担になるのではないか
このあたりは自動化だったりで改善できると良いなと思っている。
課題はあるが、セキュリティ強化の一歩を踏み出せてよかった。