目次

GitHub 漏洩事件から見るセキュリティ担当者向けの対応策

現在ニュースになっている GitHub （ギットハブ）を利用した三井住友銀行の情報漏えい事故が有りました。 コチラに対する、セキュリティ担当者向けの解説・対応方法のススメの記事となります。

※　こちらは、あくまでも個人のブログとなります。 　　実際の対策は、組織として意思決定をお願いいたします。

事件のあらまし

三井住友銀行などのソースコードが流出　“年収診断”したさにGitHubに公開か - Yahoo! ニュース

システムエンジニアとして従事していた男性が、GitHub というクラウドサービスに業務委託元のソースコードを掲載したものです。

これにより、各社のセキュリティ体制や、利用者のセキュリティ担保に問題が発生している事故です。

GitHub とはなにか？

GitHub は、世界中のエンジニアが利用しているコード管理システムです。 プログラムのソースコード（開発者が記載するプログラム）をバージョン管理することが目的であり、世界中で利用されているクラウドサービスです。

各プログラムの格納場所（フォルダのようなもの）をリポジトリとよび、世界中に公開するもの、非公開で運用するものを設定できます。

窓の社のようなプログラム配布サービスの側面もあり、エンジニアが使うエディタ（高機能なメモ帳）やその拡張機能、ライブラリ（世界中の有志が作ったプログラム機能）などの 配布サービスとしても利用されています。

クラウドサービスとしての GitHub の他、企業が管理できる GitHub Enterprise もあります。

原因の特定および分析

今回の事故の原因をリスク分析し、その影響度を含めいくつか列挙したいと思います。

• 業務委託終了・退職後も受託ソースコードを有していた。

  • 影響度：大
  • 掲示板や、他社の業務への流用など、影響が大きい。

• 本人が情報漏えいに対して無頓着であった。

  • 影響度：大
  • 業務委託元ソースコードが漏洩することを問題として認識できていない。

• 本人が現状の年収に不満を持っていた。

  • 影響度：小
  • 委託元に損害を与えようとする意図は見えていない。

• GitHub に情報ソースをアップロードできた。

  • 影響度：小
  • メールや、掲示板への投稿などの選択肢がとれ、影響度は小さい。

簡単に考えるところで上記の原因が特定できます。

今回、本人が業務委託が終了し、退職後も情報を有していたところ、また、本人のセキュリティ意識が欠如していたことの影響が大きいと判断できます。

管理策の案

上の章で特定した原因に対する対応策を考えてみたいと思います。

業務委託終了・退職後も受託ソースコードを有していた。

通常、業務終了後に受託業務で利用した資料一式は破棄していると思われます。 また、退職時に持ち出しが無いように誓約書をとっていると思います。

これ意外の対応について私が対応したことの有る対応策で有意であると思われるものを記載いたします。

ハイリスクな従業員に対して対処する。

主に、ハイリスクとされる従業員に対する対応を強化することが有効です。 退職する社員、現状に不満を持っている社員、再委託先、フリーランス、SES（システムエンジニアリングサービス）という業態は、帰属意識、自身へのリスクが少ないために事故を起こしやすいです。 意図して情報漏えいを起こす危険性が高いです。

帰属意識が下がるほど事故を起こしやすいため、フリーランス、SESといった自身の組織との関係性が低いところは特にハイリスクであるため、 委託先や再委託先としてこういった契約形態を制限することも有意な対策となります。

業務終了後の破棄作業を確認する。

契約終了や退職に際して、情報削除を徹底させる事が考えられます。

個人のパソコン、メール、クラウドサービス（特に、個人契約のもの）などに情報が残っていないか、チェックシートなどを作成し確認させることが考えられます。 特に、自身の作成したもの、自身が受け取ったものなど、個人の所有と思えるものは、意識せずに持ち出す傾向にあります。

ビジネスクラウドサービスを推奨する。

禁止ではなく、推奨によって外部への持ち出しサービスを利用させることも考えられます。 GitHubには、一般のクラウドサービスの他に組織として管理できる GitHub Enterpriseと言うものがあります。

こちらを利用させることにより、個人契約のクラウドサービスなどへの情報漏えいを抑止することが考えられます。

本人が情報漏えいに対して無頓着であった。

企業間では機密情報の取り扱いに関する契約がされていても、末端の作業者には伝わらないことがあります。 今回の事故では、本人が委託元のソースコードを利用した、漏洩させたことに対して事故であるとの認識がありませんでした。

これらへの対策を考えてみます。

作業者向けの誓約書を取得する。

当たり前と思われる対応であっても末端の作業者には伝わらないことが多いです。 企業間の契約ではなく、情報を取り扱う全員に署名を求める対策が考えられます。

これには、一般的な事項のみで簡潔にまとめるほど効果が高いです。

私が作成したことが有るものでは以下の事項を含みました。

• 悪意ある行動を取らないこと。
• 事故が発生しないように注意すること。
• 問題があった際は、すぐに報告を行うこと。
• 知った情報は、家族や仲間内を含めて共有しないこと。
• 個人の端末や、クラウドなどに情報を転送しないこと。

本内容を業務に関わる全員（委託先含む）に対して誓約書を取るだけでも、意識するようになるため効果的です。

コピーライトを記載する

コピーライトをすべての文書、ソースコードに記載することは有効であると考えます。

著作権に対して認識を持つ方であれば、コピーライトがあるものを無断複製すると罪になるという意識はあります。 今回のように、秘密を守る意識の無い方でも、漏洩後の調査が可能となります。

本人が現状の年収に不満を持っていた。

これは今回の原因としての要素は低いと思いますが、対策を考えます。

ログを記録し、確認する。

退職を匂わす社員、退職する社員はハイリスクであると認識し、ログを確認します。 一般的に情報を持ち出す社員は、メールや自己契約のクラウドサービス経由で持ち出すことが多いため、 メールやインターネット通信量を計測し、退職の直近に多くの通信を行った場合は要注意となります。

GitHub に情報ソースをアップロードできた。

こちらは、トレードオフの側面が強いです。 エンジニアの業務内容として、GitHub と通信ができなくなると作業が滞ることが考えられます。

※　機密情報のアップロードではなく、ライブラリやツールのダウンロードなど。

SIEMを用いた通信先の管理

一般的なファイヤーウォールでクラウドサービスの通信を止めてしまうと、業務が滞る事が考えられます。 そのため、 SIEMを用いて個人契約のクラウド利用や、Push（送信）の禁止などの高度な制限が考えられます。

セキュリティエンジニアとして、一律の禁止は業務が滞ることから推奨できません。

まとめ

昨今のニュースを見ていると、GitHubを知らず、コード共有システムなどとして利用を制限するのが良いようにリードするニュースを見かけます。 セキュリティエンジニアとして、このような対策は推奨できません。

今回の原因は、ソースコードを持ち出したことに重きがありますので、持ち出しを抑止する対策を検討してください。 また、エンジニアにとって価値の高いクラウドサービスですので、業務とのトレードオフを必ず検討してください。

GitHubなどには、企業向けの GitHub Enterprise などの選択肢もあります。

以上

✨ブログランキングにご協力ください✨

本サイトの記事について

本サイトの記事は、プログラミングだけでなく、雑多な雑学を多く配信しております。

もしよろしければ、ほか記事も閲覧いただけますと幸いです。