セキュア ソフトウェア開発戦略の要点

はじめに

世界の各政府は顧客の極秘データの保護を企業に義務付けるさまざまな規制の枠組みを設け、この義務を怠った企業に対して厳しい制裁を課しています。データに対して適切な安全装置を実装しないと、企業の信用と収益に重大かつ永続的な影響が及ぶことになりかねません。

問題をさらに複雑にさせるのは、ソフトウェアはあらゆる領域でビジネスの中心的コンポーネントとなっており、その重要性は今後も高まっていくことです。その一方で、厳格な規制要件とコンプライアンス要件によって、チームの実行プロセスから使用ツールに至るまで、ソフトウェアの開発方法が左右される可能性があります。特に医療、行政、金融サービスなどの高度に規制された業界の組織においては、これらの要件はパフォーマンスを低下させ、イノベーションを阻害するほど厳格であることも少なくありません。

ここでの良いニュースは、セキュア開発がコラボレーションやイノベーションの妨げになる必要はないということです。現代の企業では、影響力が強く先進的なユーザーエクスペリエンスを創造できる独自の位置を占めており、多くの企業がそれを実現しています。何千もの組織が GitHub を利用して、閉鎖的な開発からワークフローを解放し、エンジニアリング チームが最高の成果を挙げるための柔軟性を提供するセキュアなプロセスを構築しています。消費者の期待がこれまでになく高まっており、コスト削減への圧力が増す中で、効率的かつセキュアで協力的なワークフローは、チームがその焦点を最も重要な事柄、つまり顧客のために最も革新的な最高のソフトウェアを構築することに移行させるために役立ちます。

このガイドでは、ソフトウェア企業が直面する特有の規制や技術的な課題、それらへの対処方法、および GitHub の活用方法について紹介します。

顧客データを保護する

現在、顧客はオンライン取引やその他のデータ交換で、最も機密性の高い極秘データの一部を企業と共有しています。セキュリティ チームは、このデータを犯罪目的で入手しようとする者たちとの間で常に激しくせめぎ合っています。その範囲は、個人のハッカーから、セキュリティを弱体化させるために相当なスキルとリソースを投入する国家主導の攻撃者に至ります。幸い、企業が開発プロセスをセキュア化し、極秘データを保護するために役立つベストプラクティスとツールがあります。

セキュリティを保証できる単一の解決策やアプローチはありません。代わりに、効果的なセキュリティは、データパスやワークフロー全体にわたって複数のポイントで検査と安全装置を導入する、階層化アプローチに依存しています。この階層化アプローチには、ツール、プラクティス、文化の組み合わせが含まれます。

セキュリティ カルチャーを構築する

セキュリティを全ての中心に据える企業文化は、セキュリティ ポリシーを大規模に実施するための鍵となります。セキュリティ カルチャーの構築とは、全ての人の仕事の基礎になるプロセスを構築することを意味します。その例には、技術的な手段だけでなく、セキュアな慣行に関する定期的なトレーニングや、フィッシング攻撃のような社会的な侵入経路の危険性を強調することなどが挙げられます。具体的なベストプラクティスの例:

• パスワードポリシーの徹底によるパスワード セキュリティの強化 (複雑なパスワード、定期的なパスワードの変更、パスワード マネージャーやパスワード ジェネレーターの使用など)
• 2 要素認証の使用
• 公衆ネットワークの危険性に関する教育と訓練、ノートパソコン、タブレット、携帯電話などのデバイスの物理的保護
• 社内ネットワークへのアクセスを保護するための VPN の使用

データを常に暗号化する

データへの許可されていないアクセスを回避する最適な方法の 1 つは、データの暗号化です。攻撃者がデータ送信にアクセスできたとしても、強力な暗号化があればその成功の価値はほぼなくなります。この場合も、暗号化戦略を実装するときには、階層化アプローチを採用することが最も効果的です。つまり、次の方法です。

• 永続的な保存場所とエンド ユーザーとの間でデータが送信される場合、送信中のデータを暗号化する
• データが保存されているデータベース内の「保存済み」データを暗号化する

送信中の暗号化

一般的な例として、Web ベースの取り組みでは、TLS のような最新の暗号化プロトコルを使用したエンド ツー エンド暗号化を採用する必要があります。TLS は、証明書ベースの強力な暗号化を用いて通信をセキュア化するもので、実質上、基本的に解読不能になり得ます。TLS はまた、ネットワーク トランザクション内の各当事者を確認し、攻撃者がトランザクション内で信頼された相手として偽装する「中間者攻撃」を防ぎます。LetsEncrypt などのサービスにより、効果的な TLS の実装と必要な証明書の取得におけるコストと複雑性が大幅に低減しています。

保存時の暗号化

アプリケーションの中には、ソフトウェアレベルでの暗号化サービスを提供するものもあります。この種の暗号化はないよりは良いと言えますが、複雑性やパフォーマンスの低下といった膨大なコストを伴いかねません。ファイル システムの暗号化やハードウェア アプライアンスの暗号化など、ストレージ ハードウェアにできるだけ近い場所で実行される暗号化ソリューションは、全てのアプリケーションに対して透明な暗号化レイヤーを提供できます。

GitHub での暗号化

GitHub のセルフホステッド ソリューションである GitHub Enterprise Server との通信は、すべて TLS で保護されており、低価格でシンプルな証明書メンテナンスのために LetsEncrypt を使用するオプションがあります。GitHub は SSH を使用して、開発者が使用する Git クライアントとサーバー間の通信もセキュア化します。これらはどちらも強力な暗号化プロトコルであり、極秘データの不正な傍受や漏洩に対する堅牢なバリアを提供します。

強力な ID 管理手法を採用する

ユーザーが覚えなければならないパスワードが多ければ多いほど、パスワードを書き留めたり、覚えやすい (つまり推測されやすい) パスワードを再利用したりするような、安全でない習慣をデフォルトにしてしまう可能性が高くなります。LDAP のような一元化された ID 管理システムとシングル サインオン (SSO) ソリューションの組み合わせを使用することで、ユーザーが管理する必要のあるパスワードの数を大幅に減らすことができるため、ユーザーが堅固なパスワード管理慣行に従うことも簡単になります。

GitHub と ID 管理システムを併用する

GitHub Enterprise は、Active Directory や LDAP といったさまざまな ID 管理ソリューションを使用する認証と認可をサポートしています。GitHub は、企業がユーザーにシングル サインオンを提供することを可能にする SAML もサポートしています。

データベース攻撃を防止する

組織に入り込むデータは、攻撃者がシステムへのアクセスを試みる際に使用する危険な手段となる可能性があります。これらの戦略の多くは、危険なペイロードを不適切に設計されたシステムに渡すことに依存する戦略であり、欠陥を悪用してシステムを制御します。SQL インジェクションはその典型的な例で、攻撃者がウェブ アプリケーションの顧客名のような一見無害なデータに、意図的に SQL コードを追加することで発生します。基盤ソフトウェアにある欠陥は、このコードの恣意的な実行につながる場合があり、その結果、データが意図せずにユーザーに返されます。これらの攻撃は、セキュリティを監視する IT 管理者の注意を引くようなエラーやその他のイベントを引き起こさない可能性があることから、特に危険です。

繰り返しになりますが、正当なデータだけが環境に入ることを確実にするには、階層化アプローチが最も効果的です。階層化アプローチはユーザー インターフェイス内のコードから始まり、ミドルウェアを経由して基盤となるデータ ストアに至るデータパス全体に及びます。各段階でコードに検証を組み込むことにより、こういった類の攻撃に対する脆弱性を劇的に低減させることができます。頻繁な手動および自動レビューとテストの組み合わせは、この取り組みをサポートするうえで非常に重要です。

極秘データを分離する

極秘データが存在する場所が少なければ少ないほど、攻撃者が悪用できる機会 (「サーフェス領域」) も少なくなります。サーフェス領域の削減とは、パスワードの管理を個人に任せるのではなく、パスワード マネージャー内に保管して、パスワード、アクセス/API トークン、暗号化キー、およびその他の極秘データを一般アクセスが可能なリポジトリに決してコミットしないといった慣行の実装を意味します。

極秘データは決して、本番システム以外で使用したり保存したりすべきではありません。もちろん、チームにはテストのために実物を確実に模倣する大量のデータが必要になる場合もあるため、エンジニアの中には本番データを使って開発環境やテスト環境を「リフレッシュ」する誘惑に駆られる人もいるでしょう。本番データを使用する代わりに、大量のダミー データを設定に応じ生成できるツールの使用を検討してください。そうすることで、極秘情報を危険にさらすことなく、信頼性の高い現実的なテストを実施できます。

pre-receive フックで極秘データがリポジトリに到達するのを防止する

極秘データを個別に保管するだけでなく、pre-receive フックを使用して、保護されたデータが不用意に (または意図的に) リポジトリにコミットされるのを防ぐことができます。pre-receive フックは、GitHub アプライアンスの隔離された環境で実行されるシンプルなスクリプトです。GitHub にコードがプッシュされる前にトリガーされ、コミットを検査して極秘情報を特定し、 リポジトリに追加されないようにします。

コードの検査後、pre-receive フックは「成功」または「失敗」の 2 つの可能な値のいずれかを返します。失敗した場合は、コミットが失敗したことを知らせるメッセージと、含めることをチームが選択したその他の有用な情報が開発者に表示されます。コードがリポジトリにコミットされるのは、pre-receive フックが成功した場合のみです。その結果、不要なコードはリポジトリに入らず、企業は違反、法的責任の脅威、潜在的な規制上の罰則から守られます。

ソース コードに保護を施す

効果的なセキュリティには、極秘情報と、それを管理するソフトウェアのソース コードに対するアクセスの制御が必要です。きめ細かな制御とは、過度に包括的なアクセス拒否を行うセキュリティに縛られた環境を作り出すことなく、極秘情報を効果的に保護できることを意味します。GitHub では、保護されたブランチでアクセス ポリシーを補助できます。保護されたブランチは、管理者が保護することを選択した任意のブランチで Git のいくつかの機能を制限することで、コードの整合性を維持するために役立ちます。たとえば、管理者はブランチへの投稿者を特定のユーザーやチームに、プログラムによって制限できます。また、特定のブランチのコードを変更したり削除したりするような強制 プッシュを無効にすることもできます。その他の安全装置の例:

• ブランチの削除を防止する
• 自動テストや継続的インテグレーション (CI) チェックに失敗したコードをマージしないようにする
• 1 人以上の人間による、監査可能な手動のレビューを要求する
• コード ベースのあらゆる部分に対する「コード所有者」を指定し、それらのレビューを必須にする

開発プロセス全体を保護する

ソフトウェアのコード ベースと、チームの構築方法を形成する開発プロセスは、階層化セキュリティ戦略の中核となります。開発者が協力して変更に貢献する際には、ベスト プラクティスと GitHub の機能を組み合わせて特定の安全装置を導入することが重要です。

レガシー 基幹 システムを含める

メインフレームのようなツールは、最初の導入から 50 年以上経った今でも、一部の企業では中心的な存在として運用されています。これらのシステムは比類ない機能を提供しますが、セキュア化におけるユニークな課題にもなり得ます。開発チームは、全てのレガシー システムを定期的に評価し、更新するコストと、それらがセキュリティ侵害を引き起こす可能性とのバランスを取る必要があります。レガシーシステムの置き換えは、数十億ドル規模の罰金や、社会的な信用を損なう壊滅的なセキュリティ侵害が考慮されるようになるまで、コスト効率性に優れているとは考え難いかもしれません。

メインフレーム システムを選択する

GitHub のパートナー エコシステムには、メインフレーム システムを生産、販売、保守しているベンダーが多数存在します。例えば、IBM は最近、GitHub の土台となっているテクノロジーである Git の拡張機能を発表しました。これは、最新の DevSecOps プラクティスをメインフレーム開発ワークフローに適用することを可能にします。GitHub Marketplace で GitHub.com ワークフローを強化するインテグレーションを見つけるか、セルフホスト ソリューションの GitHub Enterprise Server でどのアプリが動作するかについて詳しくご覧ください。

プロセスを自動化してバグやエラーを防止する

手動での監視は、効果的な階層化セキュリティ戦略の重要なコンポーネントです。ただし、人間に頼りすぎるのは危険です。人間は疲れたり、注意散漫になったり、単に間違いを犯すこともあります。人間のスキルが最も重要とされる作業には人材を投入し、反復的で退屈ではあっても重要な作業は機械に任せましょう。チームは、GitHub ワークフローで完全に自動化された継続的インテグレーションおよびデリバリー (CI/CD) を活用できます。

コミットがリポジトリにプッシュされると、そのたびに、CI/CD ツールによってコードがテストされ、評価されます。CI/CD を導入することで、GitHub は新しいコードを既存の本番コードと共にテストして、提案された変更が意図したとおりに動作し、既存のシステムにセキュリティ上の欠陥を生じさせないことを確実にすることができます。このテストは、コードが依存する全てのコード (依存関係) の検査にも拡張できます。自動化の導入は困難ではなく、即時的で測定可能な成果をもたらすことができます。IEEE が行った 2017 年の調査では、自動化された依存関係管理を実装しなかった組織に比べて、実装した組織では納品されたソフトウェアのセキュリティ脆弱性が 60% 低いことがわかっています。

CI/CD と GitHub を統合する

GitHub を使うことで CI/CD を簡単に統合でき、自動テストの結果から対応が必要となる場合を除き、開発者の既存のワークフローに影響が及ぶことはありません。自動化が開発者にとって邪魔にならないものであればあるほど、自動化が広く採用され、組織全体でそのメリットを感じることになる可能性が高くなります。

GitHub は、Jenkins、Travis、CircleCI などのさまざまな CI ツールと統合されています。これらは、コードがプッシュされるたびに GitHub リポジトリから自動的にコードをフェッチし、テストを実行して、その結果を成功/失敗ステータスとともに GitHub に返します。また、各テストのステータスに関する通知も返すため、開発者はコードが失敗している箇所を確認できます。また、Checks API を使用すると、チームはフィードバックをシームレスで豊富な情報を提供する CI の、洗練されたカスタム ツールを構築できます。

チームは、CI テストの結果によってコードがコード ベースにマージされるのを防ぐか、何もせずに単に開発者に警告するかどうかを決定することができます。継続的インテグレーション ステータスが必要な場合、プルリクエストをマージできるのは、必要な継続的インテグレーション ジョブのすべてが完了したときにのみです。マージしないことを選択する場合、プルリクエストは必要なテストが成功するまでマージできません。

必須コード レビューにより手動レビューを強制する

自動化が重要である一方で、コードの手動レビューもセキュリティ戦略の重要なコンポーネントであり続けます。所定のコード ベースに対する監視の目が多ければ多いほど、エラーや脆弱性が発見される可能性が高くなります。また、レビューはセキュリティ以外にも価値のある役割を果たしており、組織的な知識が共有されることを確実にするとともに、あらゆるスキル レベルの開発者に学習やメンタリングの機会を提供します。定期的な組織認定のレビューの結果として、よりセキュアであるだけでなく、より健全で一貫性のあるコード ベースが実現されます。

GitHub では、コード レビューを義務付けるための柔軟な枠組みを利用できます。以下のことができます。

• 変更を含むリポジトリへの書き込みアクセス権限を持つ一人または複数のユーザーによるレビューを要求する
• 1 人以上のコード所有者による追加レビューと承認を要求する。コード所有者は、コード ベースの特定のセクション、特定のテクノロジー、またはその両方に対して特定の責任を割り当てられた個人ユーザーまたはチームの任意の組み合わせになります。
• レビューアーが、提案された変更に対して詳細なフィードバックを行単位で提供できるようにする
• 全てのレビューが記録され、将来監査できる状態にする

ワークフローを監査可能でコンプライアンスに適したものにする

今日、一部の企業に適用されている規制基準では、堅牢なログ収集と監査機能が必要です。チームは効果的なセキュリティ戦略を作成する必要があるだけでなく、それを行ったことを規制当局に対して証明する必要もあります。GitHub では、柔軟で強力なログ収集、監査、レポーティングのフレームワークを利用できるため、規制基準への遵守とそのことを証明する能力を確保できます。

監査ログ

GitHub Enterprise は、ユーザーとシステムのアクティビティに関する包括的なログを保持します。監査対象のアクティビティには、プッシュをしたユーザー、IP アドレス、操作によって影響を受けたリポジトリなど、全ての git プッシュ操作が含まれます。ログは、分析、レポート作成、保存のために外部システム (Logstash や Splunk など) に転送することができるため、規制要件への準拠を確保できます。

リポジトリをアーカイブする

保守が終了したリポジトリはアーカイブされ、「読み取り専用」モードに設定できます。これは、新しいコードがリポジトリにコミットされないようにしながら、ユーザーがそのコンテンツを閲覧することを可能にします。

強制 プッシュのブロック

Git では、開発者が変更を「強制プッシュ」することでコミット履歴を書き換えることができます。この機能はミスを修正するために必要になる場合もありますが、規制によってデータの不変性が求められる場合は問題が生じます。GitHub Enterprise では、管理者が個々のリポジトリまたはアプライアンス全体の強制 プッシュをブロックすることで、コミット履歴が書き換えられないようにできます。

ユーザーによるリポジトリの削除の防止

リポジトリの削除機能を管理者に制限できます。

セキュリティをシフトレフトする

これまで、セキュリティは二の次にされがちでした。実際、インターネットを構成するプロトコルは、セキュリティを_念頭に置いて設計されていませんでした_。後付けされたアフターマーケット セキュリティは、ないよりはましであるものの、今日の激烈な脅威環境では決して十分とは言えません。効果的なセキュリティのためには、全てのソフトウェア プロジェクトで、初期段階からセキュリティが組み込まれていなければなりません。セキュリティをシフトレフトさせるとは、セキュリティを、納品間近のタイムラインの右側から左側の初期段階にシフトさせることです。そうすることで、製品ライフ サイクルの全体を通じてセキュリティが最優先事項であり続けることが確実になります。

また、セキュリティ チームを早い時期から連携させることで、変更が困難で高額になりすぎる前に、設計、開発、保守に関する意思決定に影響をもたらすこともできます。このアドバイスはごくシンプルなものですが、リーダーシップ チームとエンジニアリング チームが賛同しなければ、プロセスはほとんど意味を成しません。セキュア開発には、全員が効果的なセキュリティ カルチャーを受け入れることが必要です。

セキュリティ カルチャーを作る

DevSecOps は、開発サイクル全体でセキュリティについて考え、それをチームと役割に分散させる考え方です。アプリケーションの構築後にセキュリティ チームがプロセスに参加しても、悪用可能な欠陥が発見されるだけで、もはや意味を成しません。最初からセキュリティ専門家が緊密に連携していれば、チームが構築しながらセキュリティを積極的にサポートする協力的なプロセスを生み出すことができます。

DevSecOps の原則では、組織がインフラストラクチャに加えてチーム カルチャーも変革する必要が生じる場合もありますが、ソフトウェアの信頼性を向上させて不測の事態を減らせるのは価値のある成果です。セキュリティの専門家をスクラム チームに招き入れ、プロセス全体を通じてセキュリティが優先されるようにしている会社もあります。

カスタマー ストーリー: Anaplan

Anaplan は、高度なモデリング ソフトウェアを使用して、データドリブンのスマートな意思決定を下せるよう企業を支援しています。また、Anaplan は、スピード、柔軟性、誠実さに重点を置き、500 社を超える企業の計画をサポートして機敏な姿勢を維持し、機会を発見して将来の計画を立てるのを支援しています。

そのスマート プラットフォームの裏には、膨大な量のデータがあります。Anaplan の 150 人以上の開発者は、データをプライバシーに保つために十分な安全性を確保しながら、複数の業界の企業にとってデータを意味のあるものにすることができる十分な柔軟性を備えたプラットフォームを作成する必要があります。同社の顧客は、Anaplan が機密性の高い財務計画を自社のデータ センターに保存していることについて信頼しています。その結果、同社は規制された財務データの安全性とプライバシーを確保するために、厳格なコンプライアンスとセキュリティ要件を導入しています。

Anaplan は、チームが柔軟で先進的なプラットフォームを構築できるよう、GitHub Enterprise Server を使用しています。

コンプライアンスは非常に重要な問題です。当社では、万全を期すために多くのツールを構築しました。全てのコミットには、全ての開発者ツールを含む全てのものをリンクする JIRA ID がタグ付けされています。GitHub はコンプライアンスに多大な影響を与え、同時に透明性の向上にも貢献しました。

Anaplan、リリース マネージャー、Jon Sandles 氏

Anaplan のビルドおよびデプロイメント パイプラインの中心となるのは、GitHub Enterprise API を利用して定期的にクエリとポーリングを行い、全てのリポジトリにわたってレポートとアラートを生成する一連の自動化ツールです。これらにより、製品チームは開発者にメールを送信したり、Confluence でレポートを作成したり、JIRA や Slack チャネルを更新したりすることにより、何が起きているか、状況を常に把握できます。

誤った JIRA プロジェクトに対して誤ったリポジトリにコードがチェックインされた場合は、プロダクト マネージャーに通知されます。プルリクエストが長期間オープンのままになっている場合は、エンジニアに通知が送信されます。コードは Sonar や Checkmarx などのツールによって継続的にスキャンされます。Chef スクリプトなどのデプロイ アプライアンスも同じように扱われます。本番環境に稼働するものはすべて、同じパイプラインをたどります。

リリースおよびプログラム管理チームはいつでも、特に本番環境へのデプロイメントが近い時点では、コードベースのコンプライアンスと準備状況を完全に最新の状態に保ちます。

まとめ

データを安全に保つことは、ビジネスの成功だけでなく、ビジネスの存続にとっても、かつてないほど重要になっています。効果的なセキュリティの実装は大変な作業に思えるかもしれませんが、必ずしもそうではありません。階層化防御の利点の 1 つは、セキュリティの実装タスクを、それほど難しくない複数のサブ プロジェクトに分割できることです。最も重要なのは、始めることです。すでに始めている場合は、テスト、検証、質問、および改善し続けることが最も重要になります。攻撃者は決して休むことはありません。同様に、あなたも休むことなく対策する必要があります。

効果的なセキュリティの実装における課題の 1 つは、ソフトウェア開発者が革新し、成長して、生産的になるために必要な自由とのバランスを取ることにあります。セキュリティが低すぎる場合、単純に効果がありません。その一方で、過剰なセキュリティは創造性を阻害したり、人々がセキュリティ取り組み全体を回避したりすることになりかねません。GitHub などのツールは、組織がこのバランスを見いだすために役立つコントロールを提供します。

GitHub の最終的な目標は、セキュリティに対する認識を脅威以上のものに変革し、顧客満足度を高め、新規顧客を誘致し、ビジネスをさらに差別化するための機会へと変えるお手伝いをすることです。良質なセキュリティは、顧客の信頼という成果をもたらします。GitHub のようなパートナーは、効果的なセキュリティ戦略につながる過程で支援を提供できます。

---

---

私たちがお手伝いします。GitHub は、堅牢でセキュア コードの構築をサポートします。GitHub がセキュア開発プロセスにどのように適合するか、ぜひ詳細をご確認ください。ご連絡をお待ちしております。