金融セクターでのソフトウェア開発 - セキュリティが重要
2018年8月7日 // 2 min read
金融ソフトウェアのセキュア開発は重要です。データを適切に保護できなかった場合、企業は深刻な影響を受ける可能性があります。
はじめに
信頼は、金融サービス機関 (FSI) とその顧客、そして FSI 同士の関係の基盤です。極秘データの悪用を防ぐ FSI の能力は、この信頼の土台です。世界中で、政府はさまざまな規制の枠組みを導入し、FSI に対して顧客データの保護を義務付け、この義務を怠った企業には厳しい制裁を科してきました。データを適切に保護できなかった場合、企業は深刻な影響を受ける可能性があります。
さらに問題が複雑になる要因となっているのが、ソフトウェアが FSI のビジネスの中心的な要素となっていることであり、今後ソフトウェアの重要性は増し続けるでしょう。ただし、厳格な規制とコンプライアンスの要件によって、FSI がソフトウェアを構築する方法は規定されており、この要件は FSI が従うプロセスから使用するツールまで及びます。これらの要件はしばしばパフォーマンスを低下させ、イノベーションを阻害するほど厳格なものです。
ここでの良いニュースは、セキュア開発がコラボレーションやイノベーションの障壁になる必要はないということです。金融機関は、影響力が強く先進的なユーザーエクスペリエンスを創造できる独自の位置を占めており、多くの金融機関がそれを実現しています。何千もの組織が GitHub を利用して、孤立した開発からワークフローを解放し、エンジニアリング チームがベストを尽くすための柔軟性をもたらす安全なプロセスを構築しています。
消費者の期待がかつてなく高まり、コスト削減への圧力が増す中で、効率的でコラボレーティブかつセキュアなワークフローは、チームが最も重要なことに焦点を移すのに役立ちます。つまり、顧客に最適で革新的なソフトウェアを構築することです。
この記事では、FSI に固有の規制や技術的な課題、それらへの対処方法、そして GitHub の活用方法について紹介します。
顧客データを保護する
FSI は世界で最も重要度の高い極秘データを扱います。FSI は、このデータを犯罪目的で入手しようとする者たちとの間で常に激しくせめぎ合っています。その範囲は、個人のハッカーから、セキュリティを弱体化させるために相当なスキルとリソースを投入する国家主導の攻撃者に至ります。幸いにも、企業が開発プロセスを安全に保ち、極秘データを安全に保つのに役立つベストプラクティスとツールがあります。
セキュリティを保証できる単一の解決策やアプローチはありません。代わりに、効果的なセキュリティは、データパスやワークフロー全体にわたって複数のポイントで検査とセーフガードを実施する、階層化アプローチに依存しています。この階層化アプローチには、ツール、プラクティス、文化の組み合わせなどがあります。
セキュリティ カルチャーを構築する
セキュリティを全ての中心に据える企業文化は、セキュリティ ポリシーを大規模に実施するための鍵となります。セキュリティ カルチャーの構築とは、全ての人の仕事を作るプロセスを構築することを意味します。その例としては、技術的な手段だけでなく、セキュアなプラクティスに関する定期的なトレーニングや、フィッシング攻撃のような社会的な侵入経路の危険性を強調することなどが挙げられます。
具体的なベストプラクティスの例:
- パスワードポリシーの徹底によるパスワード セキュリティの強化 (複雑なパスワード、定期的なパスワードの変更、パスワード マネージャーやパスワード ジェネレーターの使用など)
- 2 要素認証 の使用
- 公衆ネットワークの危険性に関する教育と訓練、ノートパソコン、タブレット、携帯電話などのデバイスの物理的保護
- 社内ネットワークへのアクセスを保護するための VPN の使用
データを常に暗号化する
データへの許可されていないアクセスを回避する最適な方法の 1 つは、データの暗号化です。悪意ある攻撃者がデータ送信にアクセスできたとしても、強力な暗号化があればその成功の価値はほぼなくなります。この場合も、暗号化戦略を実施するときには、階層化アプローチを採用することが最も効果的です。つまり、次の方法です。
- 永続的な保存場所とエンド ユーザーとの間でデータが送信される場合、送信中のデータを暗号化する
- データが保存されているデータベース内の「保存済み」データを暗号化する
送信中の暗号化
標準的な慣例として、Web ベースの取り組みでは、TLS のような最新の暗号化プロトコルを使用したエンド ツー エンド暗号化を採用する必要があります。TLS は、証明書ベースの強力な暗号化を使って通信を保護するもので、実用上は基本的に解読はできません。TLS はまた、ネットワーク トランザクション内の各当事者を確認し、悪意ある攻撃者がトランザクション内で信頼されたパートナーのふりをして行う「中間者攻撃」を防ぎます。LetsEncrypt などのサービスにより、効果的な TLS の実装と必要な証明書の取得のコストと複雑さが大幅に低減しています。
保存時の暗号化
アプリケーションの中には、ソフトウェアレベルでの暗号化サービスを提供するものもあります。この種の暗号化はないよりは良いですが、複雑さやパフォーマンスの低下といった多大なコストを伴うことがあります。ファイル システムの暗号化やハードウェア アプライアンスの暗号化など、ストレージ ハードウェアにできるだけ近い場所で実行される暗号化ソリューションは、全てのアプリケーションに対して透明な暗号化レイヤーを提供できます。
GitHub での暗号化
GitHub のセルフホステッド ソリューションである GitHub Enterprise Server との通信は TLS によって保護されており、LetsEncrypt を使用して手頃な価格かつシンプルに証明書をメンテナンスできます。GitHub はまた、開発者が使用する Git クライアントとサーバー間の通信を SSH を使用して保護します。どちらも強力な暗号化プロトコルであり、極秘データの不正な傍受や漏えいに対する堅牢なバリアをもたらします。
強力な 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 年以上経った今でも、FSI 運用では中心的な存在です。これらのシステムは比類ない機能を提供しますが、同時にセキュリティを確保する上で独自の課題を引き起こす可能性もあります。FSI チームは、全てのレガシー システムを定期的に評価し、更新するコストと、それらがセキュリティ侵害を引き起こす可能性とのバランスを取る必要があります。レガシーシステムのリプレースは、数十億ドル規模の罰金や、大規模なセキュリティ侵害が公共の信用を損なう可能性が等しい場合まで、費用対効果が低いように見える可能性があります。
メインフレーム システムを選択する
GitHub のパートナー エコシステムには、メインフレーム システムを生産、販売、保守しているベンダーが多数います。たとえば、IBM は最近、GitHub を支えるテクノロジーである Git の拡張機能を発表しました。この拡張機能を使うと、最新の DevSecOps プラクティスをメインフレーム開発ワークフローに適用できるようになります。
プロセスを自動化してバグやエラーを防止する
手動の監視は、効果的な階層化セキュリティ戦略の重要なコンポーネントです。ただし、人間に頼りすぎるのは危険です。人間は疲れたり、注意散漫になったり、単純にミスを犯したりします。人間のスキルが最も重要な仕事には人間を投入し、反復的で退屈であるものの重要な仕事は機械に任せましょう。GitHub のワークフローでは、チームは完全に自動化された継続的 インテグレーションと継続的デリバリー (CI/CD) を活用できます。
CI/CD ツールは、コミットがリポジトリにプッシュされるたびにコードをテストし、評価します。CI/CD を導入することで、GitHub は新しいコードを既存の製品コードと一緒にテストできるため、提案された変更が意図したとおりに動作し、既存のシステムにセキュリティ上の欠陥が生じないことを確認できます。このテストは、コードが依存する全てのコード (依存関係) の検査にも拡張できます。
自動化の導入は難しいことではありません。また、導入することですぐに測定可能な結果をもたらす可能性があります。IEEE の 2017 年の研究によると、たとえば、自動依存関係管理を導入した組織は、導入していない組織に比べて、納品されたソフトウェアのセキュリティ脆弱性が 60% 少なくなりました。
CI/CD と GitHub を統合する
GitHub を使えば CI/CD の統合は簡単です。自動テストの結果で対応が必要にならない限り、開発者の既存のワークフローに影響を与えることはありません。開発者にとって自動化が邪魔にならないものであればあるほど、自動化が広く採用され、組織全体でその恩恵を感じられる可能性が高くなります。
GitHub は、Jenkins、Travis、CircleCI などのさまざまな CI ツールと統合されています。 CI ツールは、コードがプッシュされるたびに GitHub リポジトリから自動的にコードを取得し、テストを実行し、その結果を GitHub に成功や失敗のステータスとともに返します。
また、各テストのステータスに関する通知も返すため、開発者は自分のコードがどこで失敗しているかを確認できます。CI テストの結果によってコードがコード ベースにマージされるのを防ぐか、単に開発者にアラートを表示するどうかは、ユーザーやユーザーのチームが決めることができます。CI ステータスが必要な場合、プルリクエストは必要な CI ジョブがすべて完了したときにのみマージされます。マージしないことを選択した場合、プルリクエストは必要なテストが成功するまでマージできません。
必須コード レビューにより手動レビューを強制する
自動化が重要である一方で、コードの手動レビューも常にセキュリティ戦略の重要なコンポーネントです。あるコードベースに対する監視の目が多ければ多いほど、エラーや脆弱性が発見される可能性が高くなります。また、レビューにはセキュリティ以外にも価値のある機能があり、組織的な知識が確実に共有され、あらゆるスキル レベルの開発者に学習や指導の機会がもたらされます。定期的な組織公認のレビューを実施すれば、コード ベースがよりセキュアになるだけでなく、より健全で一貫性のあるものになります。
GitHub では、コード レビューを義務付けるための柔軟な枠組みを利用できます。以下のことができます。
- 変更を含むリポジトリへの書き込みアクセス権限を持つ一人または複数のユーザーによるレビューを要求する
- 1 人以上のコード所有者による追加レビューと承認を要求する。コード所有者は、コード ベースの特定のセクション、特定のテクノロジー、またはその両方に対して特定の責任を割り当てられた個人ユーザーまたはチームの任意の組み合わせになります。
- レビューアーが、提案された変更に対して詳細なフィードバックを行単位で提供できるようにする
- 全てのレビューが記録され、将来監査できる状態にする
ワークフローを監査可能でコンプライアンスに適したものにする
今日、金融業界に適用されている規制基準では、堅牢なロギングと監査機能が必要です。チームに必要なのは、効果的なセキュリティ戦略の策定だけではありません。規制当局にそのことを証明する必要もあります。GitHub では、柔軟で強力なログ収集、監査、レポーティングのフレームワークを利用できるため、規制基準への遵守とそのことを証明する能力を確保できます。
監査ログ
GitHub Enterprise は、ユーザーとシステムのアクティビティに関する包括的なログを保持します。 監査対象のアクティビティには、プッシュを実行したユーザー、IP アドレス、操作によって影響を受けたリポジトリなど、全ての git プッシュ操作が含まれます。ログは外部システム (Logstash や Splunk など) に転送して分析、レポート作成、保存することができ、確実に規制要件を遵守できます。
リポジトリのアーカイブ
維持が終了したリポジトリはアーカイブされ、「読み取り専用」モードに設定できます。これにより、新しいコードがリポジトリにコミットされないようにしながら、ユーザーがそのコンテンツを閲覧できるようにします。
強制 プッシュのブロック
Git では、開発者が変更を「強制プッシュ」することでコミット履歴を書き換えることができます。 ミスを修正するために必要な場合もありますが、規制によってデータの不変性が求められる場合は、この機能が課題となります。GitHub Enterprise では、管理者が個々のリポジトリまたはアプライアンス全体の強制 プッシュをブロックすることで、コミット履歴が書き換えられないようにできます。
ユーザーによるリポジトリの削除の防止
リポジトリの削除機能を管理者に制限できます。
セキュリティをシフトレフトする
これまで、セキュリティは二の次にされがちでした。実際、インターネットを実行するプロトコルは、セキュリティを念頭に置いて設計されていませんでした。後付けされたセキュリティは、ないよりはましであるものの、今日の急速に変化する脅威環境では十分とは言えません。効果的なセキュリティのためには、全てのソフトウェア プロジェクトで、初期段階からセキュリティが組み込まれていなければなりません。セキュリティをシフトレフトするとは、セキュリティを、納品間近のタイムラインの右側から左側の初期段階にシフトさせることです。こうすることで、製品ライフ サイクルを通じてセキュリティが最優先事項であり続けるようになります。
また、セキュリティ チームを早期に関与させることで、設計、開発、保守に関する意思決定が、変更が困難でコストがかかりすぎるようになる前に影響を与えることができます。 セキュリティ チームの助言は単純なものですが、リーダーシップ チームとエンジニアリング チームが助言に賛同しなければ、プロセスはほとんど意味を持ちません。セキュア開発には、全員が効果的なセキュリティ カルチャーを受け入れることが必要です。
セキュリティ カルチャーを作る
DevSecOps は、開発サイクル全体でセキュリティについて考え、それをチームと役割に分散させる考え方です。アプリケーションが構築された後にセキュリティ チームがプロセスに参加し、悪用可能な欠陥を発見するだけでは意味がありません。最初からセキュリティ専門家が緊密に連携していれば、チームはセキュリティを積極的にサポートする共同作業プロセスを構築できます。
DevSecOps の原則を実現するには、組織はインフラストラクチャだけでなくチーム カルチャーも変革しなければならない可能性がありますが、ソフトウェアの信頼性を向上させて不測の事態を減らせるのは価値のある成果です。セキュリティの専門家をスクラム チームに招き入れ、プロセス全体で優先されるようにしている企業もあります。
カスタマー ストーリー: Societe Generale
Societe Generale はフランスの多国籍銀行金融サービス企業で、世界 66 か国に 146,000 人の従業員を擁しています。Global Banking & Investor Solutions (GBIS) は、Societe Generale の 3 つの中核事業の 1 つで、企業の銀行取引および投資銀行取引、資産管理、プライベート バンキング、 証券サービスを統合したものです。
デジタル変革は当行の戦略的優先事項であり [...] 世界トップクラスのソフトウェア企業と同じツールやプラクティスを採用することが、当行の成功の鍵であると信じています。
Societe Generale、継続的デリバリー プラットフォーム部門グローバル代表、Amir Jaballah 氏
最高情報責任者である Carlos Goncalves 氏の指導のもと、GBIS は継続的デリバリーの導入を主な目的として、情報システムの大規模な見直しに着手しました。2014 年、情報システム部門は継続的デリバリー プラットフォームに GitHub を導入し、それ以来、世界中の 3,000 人以上の従業員に採用されています。
Societe Generale の以前のソリューションに比べて、管理コストは 80% 削減されました。[GitHub] のおかげで、関係するチームの変更管理サポートに割ける時間が増えました。
Amir Jaballah 氏
2016 年末までに GBIS のソフトウェア アプリケーションの 50% を変革するという戦略目標を達成するため、GBIS の IT 部門は、同部門の統合システムおよびテスト システムとシームレスに適合する、高速で高性能なバージョン管理プラットフォームを必要としていました。開発者に高い機能性とパフォーマンス レベルの標準を提供するため、Societe Generale は集中型バージョン管理から GitHub Enterprise Server に移行しました。GitHub Enterprise Server は、Societe Generale のニーズを満たす最適なソリューションでした。
まとめ
データを安全に保つことは、ビジネスの成功、さらには存続にとってますます重要です。効果的なセキュリティを実装するのは大変に思えるかもしれませんが、そう思う必要はありません。階層化防御の利点の 1 つは、セキュリティを実装するタスクを、それほど困難ではない複数のサブ プロジェクトに分割できることです。最も重要なのは、始めることです。すでに始めている場合に最も重要なのは、テスト、検証、質問、改善を続けることです。攻撃者は決して休むことはありません。同様に、あなたも休むことなく対策する必要があります。
効果的なセキュリティを実装するうえでの課題の 1 つは、ソフトウェア開発者が革新し、成長し、生産的になるために必要な自由とのバランスを取ることにあります。セキュリティが低すぎる場合、単純に効果がありません。
その一方で、セキュリティが過剰であると、創造性を阻害することや、人々がセキュリティの取り組みを避けることにつながる可能性があります。GitHub などのツールは、組織にとってそのバランスを見つけるのに役立つコントロールを提供しています。
私たちの最終的な目標は、セキュリティに対する認識を脅威から脱却させ、顧客満足度を高め、新規顧客を獲得し、ビジネスをさらに差別化する機会へと変えるお手伝いをすることです。良質なセキュリティは顧客の信頼として返ってきます。GitHub のようなパートナーは、効果的なセキュリティ戦略への道をお手伝いします。
私たちがお手伝いします。GitHub は、堅牢でセキュアなコードの構築をサポートします。ぜひお問い合わせください。
Tags