前回は英国・国家サイバーセキュリティセンター(NCSC：National Cyber Security Centre)が公開している、ソースコードリポジトリ保護のためのガイドラインに基づいて、必要となるアクションについて、その一部(下記①-⑤)までご紹介いたしました。
本稿では⑥以降の項目について、内容ならびに対策例についてご紹介したいと思います。
『Secure development and deployment guidance』
https://www.ncsc.gov.uk/collection/developers-collection
『Protect your code repository』
https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository
①信頼できるリポジトリを選択する
②リポジトリのエクスポージャ(露出度)を考慮する
③アクセス認証情報の保護する
④シークレットをソースコードから分離する
⑤不要なアクセス権限の取り消しを行う
⑥リスクモデルに公開される(オープンな)コードの分析を含める
⑦すべてのコード変更のレビューする
⑧悪意のあるコード変更を防止する
⑨一般に公開されているリポジトリを使用する場合は自身のIDに注意する
⑩コードを確実にバックアップする
以下、引用マークがついている箇所は原文の引用です。
⑥リスクモデルに公開される(オープンな)コードの分析を含める
(組織が保有する)コードの中には、プライベートリポジトリに保存することが適切なものもあります。例えば、不正な攻撃を検知するためのコードは、そのような対策を避けようとする攻撃者にとって、特に有益なものとなるでしょう。オープンにコーディングする際には、自動テストやピアレビューなど、多くのセキュリティのベストプラクティスを採用することができます。
コードを公開する際には、公開することにより生じるリスクについても考慮してください。コードの公開によって、不特定多数の開発者によるピアレビューを通じて脆弱性を極小化し、セキュリティ品質を高められるというメリットがあります。
その一方で、逆に考えれば、ゼロデイ脆弱性が発覚するリスクがあるということです。そのため、公開するか否かは、その目的を明確にするとともに、プロダクトの性質を鑑みて考慮しなければなりませんし、原文にあるように、セキュリティコントロールを提供する機能群については、そもそも公開すべきではない場合もあります。
コードの公開以外に、第三者の「目」によりバグや脆弱性を発見するメリットを享受する他の方法としては、バグバウンティ(バグ報償金制度)を活用することも考えられます。バグバウンティの取り組みは特に米国で進んでおり、下記のようなバグバウンティ・プラットフォームが有名です。
- HackerOne
![]()
HackerOne | #1 Trusted Security Platform and Hacker ProgramReduce the risk of a security incident by working with the world’s largest community of trusted ethical hackers. HackerO...www.hackerone.com - bugcrowd
https://www.bugcrowd.com/
⑦すべてのコード変更をレビューする
特定のコードリポジトリやブランチには、本番環境へのデプロイメントを行うソースコードが格納されています。意図しないコードや悪意のあるコードが含まれないように、このマスターバージョンにマージされたコードがすべてレビュープロセスを経ていることを確認してください。
⑧悪意のあるコード変更を防止する
オープンな環境でコーディングする場合、攻撃者があなたのコードを変更したり、影響を与えようとする可能性があります。攻撃が巧妙であったり、偽装されている可能性があることに注意して、変更やプルリクエストを慎重に検討し、セキュリティ上の影響を理解してください。このようなコードがビルドやテストのインフラで自動的に実行される場合は、悪意がある可能性があるため、特に注意してください。
上記⑦および⑧については、レビューと承認のプロセスを確立し、変更が不用意に反映・実装されないようにすることで、意図せずに、あるいは故意に悪意のあるコードが含まれることを防ぐことができます。
主にはプルリクエストの利用による、レビュープロセスの確立や、コードのバージョン管理(変更・差分管理)が有効な手段です。
⑨一般に公開されているリポジトリを使用する場合は自身のIDに注意する
あなたのオンラインプロフィールに保存されている情報は、スピアフィッシングなどの攻撃を実施するにあたり、役立つ可能性があります。
一般に公開されている情報(誰しもがアクセス可能な情報)を収集・分析するような、諜報活動の手法はOSINT(Open Source Intelligence)と呼ばれ、システムの脆弱性を診断するペネトレーションテスターはもちろんのこと、攻撃者にも用いられています。
例えばオンラインプロフィールが詳細であるなど、充実していればいるほど、記載された情報を用いて、本人になりすますことが容易になってきます。仮に氏名・生年月日・連絡先などの情報が公開されていた場合、それらを利用して本人認証を回避し、特定のシステムにアクセスすることができるかもしれませんし、公開情報を用いて本人になりすまし、同僚に電話をかけるなどして、コード変更を不正に許可させることができるかもしれません。
⑩コードを確実にバックアップする
リポジトリに何か悪いことが起こったときに復元できるように、コードをバックアップしておきましょう。
サイバー攻撃によってリポジトリサーバが侵害される、あるいはハードウェア障害等によりデータが消失するリスクへの備えとして、コードのバックアップを定期的に取得しておくことが推奨されます。
読み取り専用のリポジトリサーバを用意し、ミラーリングを行なっておくことでバックアップとして代替する方法も、運用としては考えられます。また、バックアップを取得するだけではなく、可能であれば四半期に1回程度の頻度にて、バックアップから復元できることも確認してください。
まとめ
2回にわたり、英国NCSCが公開している、ソースコードリポジトリ保護のためのガイドラインに基づいて、必要となるアクションについて、その一部をご紹介いたしました。
直近では、2021年12月6日に、Line Payより13万3484アカウントの一部決済情報がGitHub上で閲覧できる状態になっていた(https://linecorp.com/ja/pr/news/ja/2021/4032)
と発表されましたが、近年、このような公開リポジトリを利用することによる情報漏えい事案は、公開リポジトリの利用増加と比例して、増えてきている印象です。
インシデントが発生することを懸念して、利便性の高いクラウドサービスやテクノロジーを活用しない、という方針をとるのではなく、まず積極的に利活用を行う、そのためにセキュリティ対策によって下支えを行う、というスタンスこそ、2021年現在の経営としては理想であると考えております。
貴社事業の推進の起爆剤として、ぜひ弊社の提供する各種セキュリティサービスをご活用いただけたらと思います。弊社では「P-SS 情報セキュリティ評価サービス」を通じて、セキュリティ対策状況を把握し、どこに弱点があるか、攻撃を受けやすい脆弱性があるかを可視化、必要な対策の優先順位をつけることを可能にします。
⇒「P-SS 情報セキュリティ評価サービス」｜PNC株式会社
https://www.pnc.jp/pss.html
ご興味がございましたら、ぜひお問い合わせください。
