ジェーシービーのクラウドネイティブプラットフォーム「JDEP」、そのセキュリティ対策とは

ジェーシービーでは、ビジネスアジリティを高めるプロジェクトを進めている。実現にあたり、さまざまな施策を実行しているが、根幹となるのが、「JDEP」と名付けたプラットフォームだ。クラウドネイティブ技術で構築し、必要に応じて外部サービスを活用しながらセキュアな運用を目指しているという。

7月23日～24日に開催された「TECH+フォーラム - クラウドインフラ 2024 Jul. 理想の環境にアップデートする」に、同社 システム本部 デジタルソリューション開発部 主幹の長沼佑樹氏が登壇。JDEPプロジェクトの概要や開発環境、プラットフォーム、アプリケーションそれぞれのセキュリティ対策について説明した。

クラウドネイティブな技術で新たに設計したプラットフォーム

講演冒頭で長沼氏はJDEPのプロジェクトについて、内製化とアジャイル開発を推進していること、スピードやアジリティの担保のため全体と異なる個別のルールやプロセスで始めていること、そしてクラウドネイティブな技術で新たなプラットフォームをゼロから設計し、その上でアプリケーションを開発するといった特長があると述べた。開発・運用の体制は、アプリケーション開発チームを、Quality Assurance （QA、品質保証）やSite Reliability Engineering（SRE）、セキュリティといった専門性のある共通チームが支えるかたちだ。

現在のシステム開発では、必要に応じて外部サービスを利用することが欠かせない。例えばパブリッククラウドを使ったり、非競争領域にSaaSを活用したり、さらにオープンソースのソフトウエアを組み合わせるなどしてシステムを構成する必要がある。セキュリティについても同様で、パブリッククラウドやSaaS、オープンソースソフトウエアなどの活用はもはや必然だ。

JDEPでも外部サービスを活用していると長沼氏は言う。開発にはGoogle CloudのGoogle Kubernetes Engineとネットワーク制御の機構であるCloud Service Meshを使い、その他共通のサービスとしてInfrastructure as Code（IaC）やCode Repo、CI/CDも活用する。開発や運用をセキュリティの面で支援するクラウドサービスとしては、ウェブアプリのWeb Application and API Protection（WAAP）やAPI保護のCloudflare、MBSD Managed Security Service、ネットワーク通信制御のNetskope、認証サービスのOktaなどを活用しているそうだ。

• 

  JDEPの環境

開発環境には共通ID基盤やゼロトラスト環境を導入

JDEPのプロジェクトには8社以上のビジネスパートナー、約500人のメンバーが参加している。そのため社員やパートナーが一体となってプラットフォームを使うためには共通ID基盤や自動化された権限管理といった仕組みが必要だ。金融機関にはIDやセキュリティに関するさまざまな規則があり、それを踏まえてセキュアに運用することも必要である。そこでJDEPプラットフォームでは共通の認証基盤としてIDaaSを用い、さらにUnified Endpoint Management （UEM、統合エンドポイント管理）やCloud Access Security Broker （CASB）、EDR（Endpoint Detection and Response）といったゼロトラストを構成するツール群を入れたプロジェクト専用端末を使うことにしている。

開発用の同端末については、開発環境や検証環境、開発ツールへのアクセスは許可するが、本番環境へのアクセスは許可しないといった対処をしている。本番環境へのアクセスは入室が制限されたセキュリティルームからのみとし、情報漏洩を防ぐためセキュリティルームからのアクセスも厳しく制限している。

そのうえで障害対応やリリースのアジリティを高めるため、ログ参照やコンテナの再起動などの定型処理については、セキュリティの前提を維持しつつリモートでも実施できるようにした。例えばリモートからのログ参照であれば、カード情報や個人情報のような高機密情報はセキュリティルームからしかアクセスできないという前提は維持したうえで、システム的な対応で必要となる高機密情報を含まないログのみを参照できるようにしたという。加えて、Data Loss Prevention （DLP）による高機密情報の削除処理も導入することで想定外の状況でも情報漏洩が起こらないように二重の保護策を講じている。

プラットフォームにも外部セキュリティサービスを活用

クラウドネイティブにおいてはシステムの変化が激しく、数も増加する。人間が対応できる限界を超えることも発生し得るため、人に依存せず、自動化やDevSecOpsに基づく対応が必要になってくる。そこでJDEPプラットフォームでも、セキュリティサービスを効率的に活用している。重視したのは、攻撃に対する防御に加えて、検知時の通知の迅速な把握とその対策をできるような環境を整備することだったと長沼氏は語る。

外部からの攻撃に対しては、外部サービスのWAAPとSecurity Operations Center （SOC）を使い、攻撃が検知された場合、SOCが検知ログを見て対応、あるいはJDEP側に通知するという仕組みだ。これ自体は標準的な対応だが、同社の場合は金融機関という特殊な事情がある。この仕組みを実現するなかでも前述のDLPと同様の処理を導入しており、SOCが扱う検知ログに高機密情報が含まれないよう徹底している。

SOCからの通知はSREが受けて運用できるようにしている。これはセキュリティであっても特別扱いせず、通常の運用に組み込むことで、インシデントの際に運用者が迅速に把握できるようにするためだ。また、SOCからの通知をバイネームで担当者に割り当ててしまうと、同じ担当者を確保し続ける必要があり、人事異動の際などにリスクが高まる可能性がある。そこでJDEPではインシデント管理SaaSを組み込み、ここから通知の重要度に応じてオンコールシフトの担当者につなぐことで、特定の人に依存しない運用体制を採っている。

セキュアな運用を維持するために活用しているのがCloud Security Posture Management（CSPM）だ。CSPMのポリシーをリポジトリで管理し、データ露呈や不正アクセスの可能性を定期的にチェック、異常の通知があれば内容を精査して対応方針を決める。さらに、その結果をCSPMポリシーに反映するという流れになっている。長沼氏は「これを定期的、継続的に行うことが重要」だと言う。管理対象であるクラウドネイティブの技術やアプリケーションは日々変化しているため、一度ポリシーをつくればそれで終わりというわけにはいかない。

アプリケーションのセキュリティ対策ではシフトレフトを推進

アプリケーションのセキュリティ対策については、初回リリースとその後で流れが変わってくるという。初回リリースまでは言わばウォーターフォールで、スプリントは設計主体、実装主体、テスト主体の順で流れる。したがってリリースの時点でセキュリティテストをすれば良かったが、リリース済みのアプリケーションが増えれば、セキュリティチームに高頻度でテストの要請が来る。そうなると、セキュリティチームに負荷が集中してしまう。

「人に依存せずセキュリティを担保するためには、DevSecOpsが必要だと痛感しました」（長沼氏）

そこで現在はシフトレフトを促すために、アプリケーションの業務ロジックやフレームワークの部分にxAST、つまりStatic Application Security Testing （SAST）、Interactive Application Security Testing （IAST）、Dynamic Application Security Testing （DAST）といったセキュリティの自動テストを導入することに取り組んでいる。これまでにもxASTを使っていたアプリケーションはあるが、プラットフォーム全体として標準ツールとして導入することで、全体のセキュリティ品質を向上させようという考えだ。

ただし、SAST、IAST、DASTにはそれぞれ一長一短があるし、これらの全てを全部のアプリケーションに適用するのはコストもかかる。したがって、例えばカード番号を扱い、外部からのアクセスもできるものに対しては高レベルのセキュリティを適用するなど、アプリケーションの特性や目的を踏まえた上で選択することが重要だ。もちろん、リスクが低ければ何もしなくてよいわけではない。

長沼氏は今後、利用形態と取り扱う情報に基づいてアプリケーションを分類、パターン化してタグ付けし、セキュリティテストや施策を自動的に判断できるようなセキュリティと効率を両立する仕組みをつくることが目標であると話し、講演を締めくくった。