🔥

GitHubは禁止するべき？ソースコード流出事件から考える情報資産の守り方

2021/01/30に公開

Security

idea

TL;DR

GitHubのアクセス自体を禁止してもセキュリティリスクは高いまま
仮にやるならGitHubのPushだけを禁止するようなツールを使わないと意味がない
GitHubでコード管理したいならアカウント管理や情報分類などの運用を組み立てよう

はじめに

先日、大手銀行などのソースコードがGitHubを経由して漏れる、というキーワードが話題になりました。
https://togetter.com/li/1659308

そもそもGitHubってなによ？って方はこちらの四コマが分かりやすいです。

これだけ聞くと相当問題のようにも聞こえますが、別にGitHubの脆弱性を突かれたたとかではなく派遣業者の社給PCないしはそこを経由した私物のPCからGitHubにPushされたという良くある情報流出ですね。なお、幸いにも重要なコードは含まれていなかったようです。

幸か不幸かこのエンジニアがGitHubに不慣れだったので非公開ではなく公開設定にしていたため、SNS上での第三者との諍いを元に発覚したという流れです。

この話を受けて、Twitter界隈ではこのエンジニアの コンプラ意識の低さ を嘆いたり、 給与が低いから問題が起こる （あるいは問題を起こすような人しか来ない）という話題が盛り上がったのですが、もう一点 「会社のGitHubアクセスが禁止されたりするかも！？」 という事も話題になっていました。なので、せっかくだし実際問題どう対応するのが良いか考えてみます。

経緯の整理

情報ソースがTwitterのコメントしかないので推察が多くなってしまいますが、経緯を整理してみます。

6年くらい前？に該当のエンジニアがNTTやSMBCなどの業務を委託会社経由で受ける（同一の会社かは不明。コメントからは会社が変わってるようにも読める）
[推測] 納品前のコードは委託先のPCで作っていたため流出コードの管理は納品前の管理はNTTやSMBCではなく委託先の会社で行っていたと思われる
業務外利用（転職サイトの利用のため）でGitHubにコードをPush。会社PCか私物PCか不明だけど会社PCと仮定（あるいは私物PCを業務に利用してるのかも）
[推測] 本人はGitHubの扱いに不慣れだった模様なので多分業務ではGitHubを使用していない
SNSで本件とは無関係に口論になり炎上した結果、GitHubなどの情報が発掘され流出が発覚

通常は業務委託や請負開発だと業務に使ったコードやドキュメントは破棄する事が契約に盛り込まれてるはずです。この辺は法務が作ったテンプレを使うだけだから大手なら案件の大小にかかわらず例外は無い。
なので、一義的には契約の履行を確認していない発注元が悪いし、契約を履行しないような会社を使った発注元が悪いし、業務指示を無視するような社員を使っている会社と契約した発注元が悪い。
「一番悪いのは犯罪を犯した本人」 みたいな話はもちろんあるしその通りなんだけど、こういうのは社会的責任は発注元に行くようになってるので発注元は責任をもってベンダーマネージメントをせねばならぬのです。言うまでもなくコンプライアンス違反をした本人は降格や懲戒を受けるし、委託会社も直接的な被害があれば請求されうるし少なくとも信頼がダダ下がりなので今後の受注が厳しくなるのは当然です。

あと、こういう会社はどうせセキュリティがザルなのでサプライチェーン攻撃がされないかマジで心配だけど、それはまた別のお話。

GitHub、禁止するべきなのか否か

今回の件だと、そもそもベンダーマネージメントがという話になるのですが、きっと皆さんが偉い人から聞かれる 「自社のエンジニアが同じことをやらかさないか？」 で考えていきましょう。

まず、GitHub云々ということで 「自分の事だ！」 と私のTLに多いエンジニアな人たちが多く反応してたけど、もう少し一般的に考えると昔からある情報資産の漏洩対策です。昔からあるという事はいまだに解決していない難しい問題という事ですが、同時に戦うための指針 くらいはあります。

システム的に情報漏洩の対策は以下の４つが考えられます。

ホワイトリストによるWebフィルタリング
ブラックリストによるWebフィルタリング
DLPによる機密情報連携の遮断
流出しても外部では開けないように透過的ファイル暗号を利用

それではそれぞれが今回の件に適用可能かを見ていきましょう。

ホワイトリストによるWebフィルタリング

最も強力で最も生産性の低い対応です。GoogleやWikipediaも含め業務に必要無いページには一切アクセスさせないという考え方です。
業務に必要ない作業をさせないとか事故防止というよりも、内部犯によるシャドーITを経由したデータ流出やマルウェアのC2サーバへのアクセスを警戒して実施するようなセキュリティですね。
実質的にインターネット接続が出来ないので業務に使用していないならGitHubにもアクセスできません。おそらくこのレベルのセキュリティが必要な組織ならコードリポジトリはオンプレミスだし、ライブラリも社内リポジトリで管理してるはずなので、最初からGitHubなんて許可されてないでしょう。

ただし、20年前ならいざ知らず現在はインターネットに接続せずに業務をするのは生産性が悪すぎます。なので、政府やそれに準ずる組織とその関連業務以外では通常は使われない最大レベルのセキュリティだと思います。なのでほとんどの企業の業務には採用するべきではないと思います。特定業務だけに適用するケースはあると思いますけどね。

ブラックリストによるWebフィルタリング

この手のセキュリティ対策で一番人気なのがブラックリストによるWebフィルタリングです。
お手軽ですし、やった感ありますし、一応最低限の効果はあるので 「とりあえず入れて置け！」 って感じですよね？実現方法も充実していてi-FilterのようなProxy、Palo Altoのような FW 、AkamaiのようなSecure DNSがあります。最近はゼロトラストの絡みでSecure DNSが人気ですね。他にもシャドーITに特化したCASBも導入してるところも多いと思います。

ただ、無闇に 「GitHubへのすべてのアクセスを禁止」 というのはやめるべきです。
まず前提としてコード管理はオンプレミスのなにかで、GitHubを使ってないとします。その場合は一見GitHubへのアクセスを全面禁止しても良さそうです。しかし、GitHubにはOSSのコードが多くあるので利用してるOSSのライブラリに問題があった時には参照する必要があります。また、パッケージマネージャがgithubからパッケージを取得する ケースもありGitHubへのアクセスを禁止するとそれらのエコシステムから切り離されます。これは大きく生産性を損ねるのでおそらく申請ベースで特定メンバーに許可する という方式になるでしょう。この場合、結局 「コードをPushしてしまう可能性のあるエンジニアのみのみ利用が許可される」 という意味のない状態に陥りがちです。
なので、大事なのは 「参照は出来るが書き込みは禁止」 という設定にすることです。幸い、最近のWebフィルタは賢いのでそういった柔軟な設定ができるものが多いです。割とレガシーよりのi-filterですら以下のように対応はしています。

このあたりの対応はかなりツールによってまちまちですがCASBなんかはそれが得意な製品なので扱いも簡単です。なのでGitHubを直接開発に利用してない場合はPushのみ禁止にする というのは結構ありな対応ですね。

一方で業務のコードをGitHubで管理されている方も結構いますよね？これは難しい。本当に難しい。
当たり前ですがGitHubで業務してるのでGitHub自体への読み書きを禁止するわけにはいきません。
そしてGitHubはサブドメインではなくサブディレクトリでリポジトリを分けます。通常はURLフィルタはFQDNに関して適用される事が多いので自社のリポジトリはOKにしつつその他のリポジトリへのアクセスを制限 という運用は難しいかもしれません。自前で立てたProxyとか使うなら比較的簡単ですが。
少なくともアカウントは社員の個人アカウントではなく会社アカウントを使うのがおすすめです。これでだいぶうっかりミスは減らせます。

追記: 無料アカウントを複数作るのは契約違反のようなので有料ライセンスを作るようにしてください。Enterpiseが良いけど予算と相談で。

URLではなく接続先のアカウントを判定するテナント制限が使えると便利なのですが、GitHub自身は対応してないですしWebフィルタ系で対応してるものがあるかは要確認。テナント制限は、たとえば特定IPからは@example.comでしかログインできない みたいな制約がつけれるのでGitHubを利用していても会社のアカウントでしかログインできなくなるのでセキュアですね。マイクロソフトの頑張りに期待。

コラム: ブラックリストのWebフィルタリングって意味あるの？

「そもそもGitHubを禁止してもGitLabや○○がある」 という話もあります。この手のシャドーIT対策は無数のSaaSに対してブラックリストを適用していくので根本的にはうっかり事故防止くらいにしか役立ちません。うっかり事故というのは 「うっかりSNSに会社の重要情報を社内チャットのつもりで書いてしまったり」 「GitHubやDockerHubにpullだけじゃなくうっかり手癖でpushしてしまったり」 「資料を共有したいとか翻訳したいとかWordをPDFにしたいとかでフィッシングサイトや脆弱性のあるサイトにうっかり社内資料をアップロードしてしまう」ことです。イタチごっこなのは事実ですが 「みんなが使いたい有名サイト」 を禁止にするだけでそれなりに効果はあるんです。個人的にはシャドーITに書き込むのは原則禁止と考えていますが、参照もできないときはちょっとイラっとしますけどね＞＜

DLP (Data loss prevention)による水際対策

Data loss preventionはデータロスとありますが、データの消失によるバックアップ的な話ではなく情報漏洩対策のこと。コンテンツを解析してルールに基づいて情報の移動を検知または防止するようなツールです。
メールやチャット、ファイルサーバに適用するケースが多いけど、ネットワーク型でHTTPを監視するものもある。通常は個人情報の有無のチェックとかで対応しますが、ソースコードの特徴をルール化できれば適用することも可能です。ただ、ソースコードに特化したものを知らないので今回のケースにはあまり当てはまらない認識。ただ、こういう対策をしておかないと社外の自宅PCなんかに持ち出されるのでやはり重要。

流出しても外部では開けないように透過的ファイル暗号を利用

ブラックリストによるWebフィルタリングは手軽ですし柔軟なのですが、根本的には 「うっかり防止」 に過ぎません。なので、今回のケースのように悪意のある情報流出を完全に防ぐことはできません。
なので 「情報流出したっていいじゃん。その代わり社内じゃないと開けないけどね？」 という考え方が透過的ファイル暗号です。
これはすごく便利なのですがツールチェインでの対応が必要になります。たとえばWord/Excel/PowerPointであればMicrosoftのAIPを利用する事で社内では特に気にすることなく開けるけど社外では開けないファイルというのを簡単に作ることが出来ます。残念ながらこの考え方に対応した開発ツールチェインを私は知りません。エディタ、ビルド、PRのタイミングだけ複合化してそれ以外は暗号化してるツールとか面白いそうですよね。まさにGitHubのようなリポジトリを中心にCI/CDのパイプラインでそういうの作ってほしいのだけどしてくれないかなぁ。

サマリ

手法はいくつかありましたが、システム的な防御では決定打は無くうっかり防止にブラックリストによるWebフィルタリングをPushに適用する あたりにとどまります。
やらないよりはずっと良い対応なんですが他に出来ることは無いでしょうか？

データを分類とリスク分析

というわけで別なアプローチも考えます。そもそもセキュリティで最も重要で最初にやることは 「情報資産の分類」 です。
これはソースコード（及び設定ファイル）であっても同様です。ソースコードであっても公開しても会社の脆弱性には繋がらないコードと、APIキーやパスワードなどのクレデンシャル、機密データを生成または含むアルゴリズム#1 、特許になるようなコアアルゴリズムなど重要度はソースコードによってまちまちです。「『全部大事』というのはですね、嘘吐きの言葉なんです」
※1 もちろんふつうは暗号とかは公開されている一般的なアルゴリズムを使うべきなので、これは業務上求められる一部の独自処理をさします。普通は無い。

ほとんどの会社では99%ないしは100%が公開しても会社の脆弱性には繋がらないコードでしょう。もちろん、これらが流出することで潜在的な脆弱性が見つかったりが考えられるし、レピュテーションリスクもあるので流出しても良いわけではありませんが、致命的ではありません。論理的には多くの企業のシステムの大部分は適切な手順でOSSというかソースコード公開しても彼らのビジネスには何ら影響はないはずです。「え、ソースコードが見られると不正操作される実装になってるって？」、それは社員が見れる時点でリスクなので速攻で直してください。

で、こういった大部分の公開しても問題ないコードとクレデンシャルやセキュリティまたはビジネス的な秘密のロジックを分離してください。そしてそれだけはガチガチの運用を適用してください。特定のユーザだけが申請に基づいて一時的にアクセスできる、というのはもちろん、場合によってはホワイトリストのWebフィルタリングで運用されることもあり得ます。一般の開発者には少なくともバイナリの状態、できれば暗号化して実行時に複合されるような作りが望ましいです。理想的にはConfidential Computingを活用するべきですがちょっとまだ早いかも？

このようにデータを分類し、リスクに合わせて運用を変えることで全部同じ運用をするよりもずっと適切な管理が出来るようになります。

まとめ

今回の件は、正直Twitterで過剰に騒がれたというのもありますが、利便性を維持しつつ情報流出とどう戦うか？という点の整理は出来たかと思います。
インターネットの利用やSaaSの利用は生産性を拡大する強力な武器なのですが、情報漏洩のポイントにもなるので適切なリスク分析、セキュリティツール、運用、ガバナンス教育をしっかりすることが重要です。とりあず安易にGitHubのアクセスごと禁止するのは意味ないので、月曜日の偉い人との戦いに備えましょう！

それではHappy Hacking！