1,000 人の大規模開発組織に脆弱性とライセンスの管理フローを構築 - 株式会社TKC
株式会社TKC
業種：情報サービス
事業概要：会計事務所と地方公共団体に特化した情報サービスを提供
従業員数：2,398 名（2021 年 9 月 30 日現在）
昭和 41 年の創業から、全国の会計事務所と、地方公共団体の 2 領域に特化した情報サービスを提供し独自の地位を築く。TKC は、本社の所在する「栃木県」の名門企業であり同時に東証プライム上場企業。企業の財務情報や自治体のマイナンバー情報など、いわば「社会的にも極めて重要度が高い情報」を扱う同社は、独自データセンターを運営し、ソフトウェアの開発や、セキュリティを含む各種運用を行うエンジニアが約 1,000 名を数える。
💡 課題背景
- システム開発の際に OSS の利用機会が増えており、脆弱性とライセンス管理が喫緊の課題となっていた
- 総勢 1,000 人のエンジニアという、大規模開発組織を横断する運用フロー構築が求められた
🙌 導入の決め手・導入効果
- 使いやすい yamory によって、OSS の脆弱性とライセンス管理フローを 1,000 名規模の大規模開発組織において構築できた
- 競合製品と比較して価格性能が高く、メリットがコストを上回ると判断できた
- 競合製品と比較して、ソースコードを提供しなくてよい製品仕様も評価された
🖥 活用シーン
- 利用手順に関する情報をイントラネットで共有し、チーム作成依頼から日々の運用まで全て yamory で完結できるようにした
- プロダクトリリース時に、yamory のスキャンで脆弱性がないことおよび、使用している OSS について記したリストを提出しなければ承認が通らないルールを設けた
1,000 名規模の技術者集団を束ねる TKC の組織体制
――お二人の自己紹介をお願いいたします
久津美氏：
TKC は、会計事務所とその関与先企業に対してシステムやサービスを提供する会計事務所事業部と、全国の市町村に対して住民サービスを展開する地方公共団体事業部との、大きく 2 つに事業が分かれています。私は、会計事務所事業部のシステム開発研究所で、品質保証部の責任者として、品質に関する責任を負っています。
中西氏：
私は、地方公共団体事業部に所属して、開発業務の中のユーザ・インターフェイス設計部という部署に所属し、自治体向けシステムの設計業務を担当しております。
――総勢 1,000 名規模のエンジニアがいらっしゃるそうですね
久津美氏：
全従業員は約 2,500 人程度で、そのうち約 7 割が会計事務所事業部、約 3 割が地方公共団体事業部に所属しています。この 2,500 人のうち約 1,000 人がシステム開発と、開発したシステムを運用するエンジニアです。
――全社的なセキュリティ管理はどのように行われていますか？
久津美氏：
情報セキュリティ戦略室という、どちらの事業部にも属さない独立組織があり、そこが全社のセキュリティを担っています。会計事務所事業部、地方公共団体事業部は、情報セキュリティ戦略室が定めたセキュリティ担保のための方針に従って、ルール設計などを行います。
各プロダクトのセキュリティは、それぞれのプロダクトの開発側が責任を負う形になっています。
――たくさんの開発者がいらっしゃる組織で、プロダクトのセキュリティ担保のために具体的にどんな施策を行っていますか？
久津美氏：
弊社は自社のデータセンターでサービスを展開していますが、サービス提供前に脆弱性診断ツールを使って脆弱性がないことを確認し、サービス展開後も定期的に脆弱性がないことを確認しています。開発と運用は分かれているので、診断は運用側で行われています。
OSS 利用の二大リスク、脆弱性とライセンス
―― yamory の導入目的を教えてください。どのような課題があったのでしょうか？
中西氏：
地方公共団体事業部では、新しいサービスやシステムを開発する際に、限られたリソースの中で効率的に開発するために、OSS の活用が増えていました。一方で、OSS を使うにあたってはその脆弱性が課題です。市町村様は重要な個人情報を扱っているので、必ず脆弱性のない開発を実現しなければなりません。
もうひとつはライセンスです。近年 IT に詳しいユーザー様から、OSS の使用有無とライセンスについてお問い合わせをいただいたこともありました。また、世間的にもライセンス違反で訴訟に発展した事例もあり、脆弱性とライセンス管理、OSS の利用にあたってこの 2 つをリスクと考えました。
久津美氏：
個人情報や企業の機微な情報を扱っていますので、情報漏えいはお客様にとっても会社にとっても一番のリスクと捉えて、真摯に取り組んでいます。また近年は、クラウドサービスが普及して共同利用化が進んで、短期間で高品質なサービスを展開しなければいけないため、OSS の利用は避けられません。
―― yamory 以外に検討していた製品はありましたか？何が yamory 導入の決め手になりましたか？
久津美氏：
海外製ツールをある会社さんから紹介され評価したのですが、一番のネックがコストの高さでした。自前でもできると考えた時期もありましたが、やはり難しそうだなと。そんなとき、たまたま私が yamory を目にして、価格的に非常に魅力的でしたので約 1 年かけて評価させていただきました。検証の中で、ライセンス違反の検知機能を要望させていただいた所、スピーディーに実装いただいたこともあり、理想の管理ツールとして評価し、契約しました。
「海外製ツール」「自前」「yamory」の三択の中で、やっぱり餅は餅屋ではありませんが、万が一何かあったときに相当なリスクをわれわれが負うことになるので「セキュリティを専門に扱っているところを使った方がいいだろう」という判断で yamory に決めました。また、海外製ツールにはコスト以外にも、ソースコードを提供しなければならないハードルがありました。
yamory を通らなければサービスローンチできない承認フローを構築
――運用フロー策定から、導入、運用定着までの具体的プロセスを教えてください
久津美氏：
評価期間を 1 年間いただき、いくつかのプロジェクトで実際に運用フローを回して、アラートが出たときどう対応する等のケースを複数作りました。その上で最終的な導入タイミングでは手順書を準備しました。
システム開発研究所とシステム開発本部は毎月 1 回、情報共有化会議という会議体を持っています。そこで「今後 OSS を利用する場合は必ず yamory を使ってください」と通達して、さらにシステム開発研究所の所長またはシステム開発本部の本部長から、yamory を使って脆弱性およびライセンス違反がないことの承認をもらわなければサービスローンチ自体ができないように業務フローに組み込みました。
これで、yamory によるスキャンで赤と黄のアラート※がひとつもなく、かつライセンス違反がないことが必ず確認されるようになりました。
※yamory では、検出された脆弱性に対して自動的にリスクの優先順位を判定するオートトリアージ機能(4 段階評価)を実装しております。「Immediate（赤のアラート）」「Delayed（黄のアラート）」は上位 2 つのリスク評価に該当します
中西氏：
私の部門も、社内イントラに yamory 利用時のガイドラインを掲載しています。ここでは、yamory スキャン処理の自動ビルドへの組み込み、設定方法も公開しており、エンジニアであれば誰でも支障なく開始できるようにしました。
――その後は手離れして運用いただいているということですね
中西氏：
そうです。yamory のダッシュボードは、エンジニアが直感的に理解できる、本当に見やすい画面だと思っています。日々チェックがかかって結果が返ってくる仕組みが yamory にあるので、チェック結果を確認し対応する業務の流れができています。
――リリースの際に yamory のスクリーンショットを証跡として提出するなどのプロセスがあるのですか？
久津美氏：
システム開発研究所では、開発で使用した OSS の一覧を yamory のデータから CSV で切り出して「このプロダクトではこの OSS を使って、バージョンはいくつで、ライセンスは何」であるかがわかるファイルを、承認を受けるとき添付しています。
中西氏：
地方公共団体事業部では、yamory の診断結果に赤色と黄色がない状態、すべてが緑シグナルになっている状態でリリースするという運用をしています。リリースのタイミングで、どうしても脆弱性が残ってしまうときには、開発担当者が「対応中」というステータスに変更したうえで、「近日中に行う○○の対応とあわせて対応するため」といった理由などのコメントを残すルールにしています。
脆弱性探しのワンステップがなくなった効果
―― yamory を導入してどんな効果を実感していますか？
久津美氏：
今までは脆弱性を自分で探しに行かなければならなかったのが、いまは新しい脆弱性があればアラートがメールで通知されるので、とにかくエンジニアが開発に専念できます。ワンステップ減ったことが非常に効率を上げています。
中西氏：
私もその通りで、探しに行くのではなく、待っているというところが一番大きいと思います。ですので、もう以前の運用に戻れないというのが正直なところです。
――今後どのようなことを yamory に望みますか？
久津美氏：
アプリケーションライブラリ以外にも、コンテナやホストのスキャンにも yamory の機能を深掘りして使っていきたいと思っています。「戻れないツール」という話がありましたが、今後ゼロデイアタックが増えてくることなどを考えると「yamory を使っていれば製品のセキュリティは盤石である」そう言えるように yamory ができることが増えていくことを期待しています。
中西氏：
私の部門は複数のプロジェクトチームで管理しているので、あるチームが対応した脆弱性と同じものが別のチームで検出されることがあります。中には対応に横展開が必要な脆弱性もありますので、対処法などをチーム同士で共有できる機能があればいいと思います。
久津美氏：
現在、そのライブラリを使っていいかどうかの判断基準として普及性を確認しています。「ダウンロード数」「GitHub で星が何個ついているか」「NuGet のユーザー数」「過去 1 年以内のリリースの有無」等々、複数のポイントを総合評価して普及性を判断し、承認プロセスにも組み込んでいます。わざわざ調べなくても yamory が普及ランキングのような情報を提供してくれれば役立つと思います。
「明日からでも」「今すぐにでも」yamory が消せるリスク
――脆弱性管理に悩んでいたり、具体的な行動に踏み切れない企業へメッセージやアドバイスはありますか？
久津美氏：
私自身 OSS に深い知識もなく、セキュリティ専門でもない中で、OSS の脆弱性とライセンスの管理をすることになって、時間をかけて調査や評価を行った結果 yamory を使っていますが、今は「yamory を使っていれば安心だ」という実感があります。先ほどの「後戻りできない」というのは、まさにこのことだなと思いました。yamory を使えば今すぐにでもリスクを軽減できますし、いま思うといろいろ悩む前に yamory を使った方が良かったなと思います。
中西氏：
私もほぼ一緒です。机上で考えるより yamory を一度でも評価すればその効果がわかると思います。明日からでも始められますから、まずはその効果を体験するといいと思います。