TwitchからのソースコードとDBダンプリストの漏えいインシデントは、様々な余波を引き起こしていますが、開発陣は、最も重要であるソースコード管理について改めて考える切っ掛けにすべきかも知れません。
securityboulevard.com
先週、Twitchは、すべてのオンラインサービスが避けたいと望んでいる一種の悪夢のシナリオに直面しました。それらのソースコードとデータベースダンプはインターネット上で漏洩し、広く配布されました。データベースダンプは、ユーザーの苦情からストリーマーの支払いまで、ビジネスに関する詳細を公開しました。また、ソースコードは、サービスとインフラストラクチャの内部動作を明らかにしました。特権VPNユーザー、キーホスト名、すべてのアプリケーションコンポーネント、およびこれらのリソースにアクセスするために必要なすべてのパスワードとキーを識別します。
このような違反の根底に到達するには、徹底的な調査、外部監査、および忍耐が必要です。私たちの誰もが迅速な答えを期待するべきではありませんが、それは多くの部外者が推測するのを止めませんでした。最終的な原因が何であるかに関係なく、これから私たちが引き出すことができるいくつかの教訓があります。
キタきつねの所感
Security Boulevardの記事では”教訓”と題して、Twitchリークから得られる事をまとめています。
今風に言えば、”性善説”から”性悪説（≒ゼロトラスト）”へのシフトをすべきと言う方が正論に近いかとは思いますが、記事では「人はミスをするもの」という開発者側の”事情”も取り上げられているのは多くの方にとって参考になる点かも知れません。
まず開発者のみならず企業のセキュリティ統括部署が改めて理解しなければならない事として、ソースコードが組織の重要資産であり、攻撃対象になっている事が挙げられています。
ソースコードは資産であり、攻撃ベクトルでもあります
「すべての会社はソフトウェア会社である」という当然の結果として、すべての会社のソフトウェアは戦略的資産であり、ソースコードは会社の内部の仕組みを明らかにします。
また、コードで管理する範囲（コードのトレンドとしてのインフラストラクチャ）として、多くの企業が対話するすべてのサービスを管理するためにgitopを使用することが増えているため、攻撃ベクトルとしてのコードの重要性は高まるばかりです。
（Security Bloulevard記事より引用）※機械翻訳
開発者・セキュリティ部署の双方にとって重要なのは、資産の保管場所（資産棚卸）と責任者（責任分界点）の状況把握と言い換えても良いのかも知れません。
今やソースコードがGitに置かれているのは当たり前の事ではありますが、多くの開発者がアクセスする環境において、重要資産はどこにあり、誰が管理しているのか？
よくありがちなリスクアセスメントでは、Excelの表に数行ソフトウェア資産の定義があったとしても、セキュリティ対策済の所に「〇」をつけて『終わり』という事が多いかと思いますが、往々にして責任者である、開発部門の管理職は全ての資産を把握していません。
開発者も多くの場合は多人数で開発するので、「誰かが管理しているだろう」とGitのブラックボックスの中でセキュリティは”軽視”されている可能性があるかと思います。
こうした隙を攻撃者が狙っている事を忘れてしまうと、いくつかのミスがインシデントに繋がってしまう、それが現在多くの企業・組織の開発環境が置かれている現状なのではないでしょうか。
また、シークレット管理も見過ごされている課題かも知れません。
記事では以下の様にシークレットが意図せず”共有”されてしまうリスクが挙げられていますが、これも各々の責任が曖昧で、開発プロジェクトに関与するスタッフが「やってはいけない事」の理解が不足している事が影響しているのかと思います。
あなたがそれを書き留めればそれは秘密ではありません
秘密の古い定義は、一度に1人しか話さなかったものでした。シークレットをリポジトリに配置することは、シークレットを必要とするコードとリソースの管理の問題に対する便利なソリューションですが、コードは共有されることを意図していることがよくありますが、シークレットはそうではありません。
（中略）
シークレットを安全に管理するためのツールが存在するようになりました。私はポータブルでオープンソースのHashicorpVaultのファンですが、すべての主要なクラウドにもソリューションがあります。残念ながら、これらのツールはまだ新しいものであり、多くの組織では、安全でない秘密のストレージを中心に複雑なシステムが構築されています。
（Security Bloulevard記事より引用）※機械翻訳
SecDevに取り組んでいる企業・組織も多いかと思いますが、Securityの観点では、シークレット管理（権限付与）は恐らく最優先の検討ポイントかと思いますが、特に外部に置いている領域においては、そのリスクを十分に検討した上で保管手法を決めるべきかと思います。
とは言え、何でも開発側に責任を寄せれば良いのかと言えば、そうではないかと思います。記事では特権付与に関する下記の様な適切なツールの必要性を挙げていますが、これだけではなく、全て開発側に”人的対応”を求める事なく、必要に応じてセキュリティ対策に予算をつける事が肝要です。
最小特権のポリシーに対して開発者が仕事をするために必要なアクセスのバランスを取るのは難しい
コラボレーションはイノベーションにつながり、リポジトリへのアクセスを待っている開発者よりも早くモチベーションと進歩を損なうものはないため、リポジトリに人々を招待します。コンウェイの法則に注意を払い、組織全体で革新を熱望している高性能の開発者は、企業で使用されている従来のアクセス管理ソリューションに夢中になり、作業を狭めます。しかし、Twitchの侵害が内部脅威であったというリスクは無視できません。
開発者は、特権を簡単に付与でき、不要になった人を簡単に見つけることができる最新のツールを必要としています。
（Security Bloulevard記事より引用）※機械翻訳
開発の実情を考えると、過度なセキュリティ対策が開発スケジュールに影響を与えてしまう可能性も出てきてしまうので、開発陣だけでなく、関係者全員が（関係者会議の議題としてセキュリティ検討を入れた上で）リスクと開発進行のバランスを取ってプロジェクトを進める、将来自社サービスがTwitchリークの様にならない為に重要な事だと思います。
本日もご来訪ありがとうございました。
Thank you for your visit. Let me know your thoughts in the comments.
更新履歴
