連載：DXにおけるDevSecOpsとは？「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」「DevSecOps Days Tokyo」レポート④

一般講演「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」

株式会社ブレインパッドの湯川です。エンジニアリング推進部に所属し、大規模案件の開発部隊で、その基礎となるシステム開発の標準化を担当するかたわら、受発注予測システムの構築、運用等も行っております。DevSecOpsに関しては試行錯誤しながら、個々の受託案件で少しずつ実践しています。

まず、私は受託開発においてECサイト、証券取引システム等のオンライン系のシステムや、社内・学内ポータルといった組織内で利用するシステムの開発を行ってきました。直近では他には、発注予測システムや、リアルタイムでポイントを集計するシステムや、機械学習を利用した受発注予測システムを担当しております。
今までに担当したプロジェクトはウォーターフォール型で進めることが多く、大きく要件定義、設計、製造・テスト、運用・保守というフェーズに分けて進めることが多かっように思います。

各フェーズの中で、脅威分析やリスク分析、セキュリティ要件を決めたり、チェックリストを作ったりといったセキュリティ対策をしてきました。特に設計フェーズではセキュリティ方式、暗号方式、連携方式、アクセス制御（認証・認可）についての設計を行ってきました。

製造・テストフェーズでは、セキュア・プログラミングの他、使用するライブラリのチェックやソースレビュー、静的解析をして、不具合や脆弱性がないかを随時チェックする運用を行い、リリース後も脆弱性情報の収集や定期的な診断、パッチ適用、インシデント対応といった運用・保守を行っています。DevSecOpsという概念がない時代からセキュリティ対策は行ってきていますが、いざ実践しようとすると色々な箇所で苦戦するポイントがあり、それを説明したいと思います。

セキュリティ対策で苦戦する各ポイントとその対策

特に苦戦するポイントは、ウォーターフォール型の開発プロジェクトにあたってセキュリティ対策の優先度が低くなるというところです。ウォーターフォール型の開発では、より具体的な作業を実施する後半のフェーズで問題が発覚しやすいことや、開発期間も長いものが多く、問題が要件変更も度々あるので、作業のやり直しも発生します。

開発には予算と納期があるため、限られた中で対応を行う場合、画面など見える部分に対しての優先度が高くなりがちで、裏側の機能で見えにくいセキュリティ担保についての優先度が低くなることが多くありました。セキュリティの担保作業は各機能の中に暗黙的に入っている事が多く、見積もりなどではセキュリティ対策の優先度をあえて「高」と書き、重要度を大げさに訴求するという対策をしました。このように意識改善を進めることが重要だと思います。

ウォーターフォール型で後半に問題が発生しがちな理由はプロジェクト初期で実施する要件定義や設計はドキュメントベースで作業するために、実際に動かさないと抽出できなかった問題が、製造フェーズやプロジェクト後半のテストフェーズではじめて発覚することが挙げられます。重要な問題が発生した時はすでにプロジェクトの後半になっていたということが多いのです。また、多忙がゆえに、目に見えにくいセキュリティ対策が遅くなってしまったというケースも多く見受けられます。

その対応としては要件定義のチェックシートを作ったり、セキュリティ要件の内容を軸として、各フェーズでチェックすることが重要でしょう。これらのチェックは製造だけでなく、要件定義や設計、運用の段階でもチェックを繰り返していくことが重要です。また、プロジェクトによっては半年、長くて2～3年かかる場合もあります。その間に脆弱性が発覚し、開発言語自体やミドルウェア、ライブラリが陳腐化した場合、それらを入れ替えなければなりませんし、協力会社のメンバーが途中で代われば、セキュリティに関する再教育する必要もあります。その際にも同じ指針をベースとした教育やチェック作業が重要となってきます。

さらに、ドキュメント化や、チームの意識を共通化することもポイントになります。どうセキュリティを守るのかという軸をベースにドキュメント化、情報共有をすることが重要です。そしてそれを実施する勇気も必要になります。変更による作業のやり直しも発生します。確かにやり直すことは怖いかもしれませんが、それらの作業の自動化やデータがあれば難しくないでしょう。

最後に、要件変更や、要件が曖昧だったために失敗することもあり得ます。例えば、一度でも仕様が変わるとセキュリティ対策を再考しなければなりませんが、同じ作業をやることは誰もが嫌がり、士気も下がると考えられます。これをフォローするためには、若干無理をしてでも自動化をした方がいいというのが私の意見です。

具体的には、機能テストの中にはセキュリティテストを含めることです。例えばセキュリティがチェックできるツールを利用して静的解析を行うことや、それ以外には認証済・アクセス制限済の設定を含んだインフラ回りの自動構築を行うことで工数削減や人為的なミスを防ぐことができます。これらの作業工数をあらかじめ見積もりに入れることが重要です。

そしてプロジェクト完了時に、振り返り作業や情報共有の場を設け、他のプロジェクトメンバーや社員に共有しています。これは文化の問題でもあるので、最終的にはセキュリティ対策を当たり前に行う土台を作ることが重要になります。

今後は社内の情報共有や過去プロジェクトの再利用が重要に

さて、今後注力していきたいことをご紹介します。受託開発では基本的に納期や予算の枠組みがあるので、コストをかけずにDevSecOpsを実現するよう模索しています。セキュリティ対策は時代によって変わるので、専門家と協業し、トレンドを取り入れることが重要です。

あとは、過去のプロジェクト資産の流用でしょうか。対策や資産の再利用、標準化、不具合管理表などです。そして、社内の情報共有も欠かせません。ブレインパッド内ではドキュメント化や分科会、部の合流なども行っています。私のいる部署ではセキュリティチームを発足し、何を守るか、どういう暗号化のアルゴリズムを採用するか、どんな脆弱性検査ツールを使うかなど、標準化の策定を進めています。

AI/MLを利用した開発案件でのセキュリティ対策を重視する

ブレインパッドではAIやMLを利用した開発をしており、その中でDevSecOpsをどう活用するかについて簡単にご紹介します。AIやMLの開発案件は、通常検証フェーズ(PoC)で問題ないようであれば、システム開発に進むという流れが多いでしょう。セキュリティ対策について気を付けることは、通常のシステム開発とほぼ同じで、モデルや学習・予測に利用するデータに対してのアクセス制御や認証・認可の実施、どうするかを考えます。あとは特に個人情報の取り扱いに気を付けることが必要です。

例えばAIやML開発でセキュリティ対策を実施する場合は、PoCの段階で対策を決めておき、システム開発時に利用することができます。通常のシステム開発と比べると、こういった期間があることはチャンスだと思います。
PoCの段階で、何を守るか、データの機密性は十分か、このモデルならどういった攻撃をされる可能性があるかなど、セキュリティの検証も同時に行っていくといいのではないでしょうか。

ここからは、弊社内である程度ML案件をこなしてきた中、どういったセキュリティ対応をしてきたかについてご紹介します。まず、個人情報はできるだけ蓄えないようにしています。例えば車のナンバーや個人の顔の情報について、エッジAIでカメラ内のデータを送る時に、数字の羅列のようなものに変換してサーバーに保管しておきます。

もう一つの事例は、これらの案件の特徴として不確実な結果を扱う場合が多く、例えば自然言語処理を利用した検索等では結果文字列が想定できず、音声をテキスト化する場合に誤認識が起こることもありますので、あらかじめ表示がNGとなる文字列を決めておき、フィルタリングしています。

最後は、モデル自身をどう守るかということです。機能を保護するという意味で、直接モデルを提供するのではなくAPI経由で提供したり、モデルは提供するものの、出力結果を加工することで直接モデルの出力結果を提供しない方法で対応することもあります。現在は、予測の入出力から学習データの推測、モデル自身を複製するといった研究が行われていますので、モデル自身の脆弱性にもこれから注力されてくるでしょう。

DevSecMLOpsを推進したい

今後推進していきたいことは、セキュリティ対策の工数削減を目的とした、完全サーバーレス化への移行です。OSを管理するとセキュリティに関する対応が増えてしまうので、できるだけサーバーレスにしたいという考えです。ただ、サーバーレスの場合のセキュリティはクラウドベンダー側に依存する部分があり、責任の所在が難しいところです。どこまで担保するのか、クラウドベンダーと調整しながら進めていく必要があるでしょう。

また、モデル自身への攻撃に対する具体的な対策やMLOpsも推進したいと考えています。MLOpsの考えをベースとしたモデルの自動デプロイやバージョン管理については実践中ですが、精度劣化時に自動的にモデルを変えるかといったことにチャレンジしたいです。MLOpsとDevSecOpsを並行で実施し、「DevSecMLOps」を推進できればと思っています。

セキュリティ対策を企業の文化として昇華させることが重要

まとめると、DevSecOpsはなかなか一朝一夕で出来るものではないため、少しづつ実践していくしかありません。また、セキュリティ対策を行うということを当たり前のものとして根付かせ、いかに企業の文化として昇華させるかが重要でしょう。また、受託案件では工数削減や納期短縮を考慮し、それには自動化された環境を構築することが、今後の大きなポイントになると思います。

AIやMLを利用する開発に関しては、基本的な部分は通常のシステム開発と同じですが、それならではの独自の考慮点も出てくるでしょうし、攻撃する側も時代によって変化してくると思いますので、それらを意識していく必要があります。

※本記事は、DevSecOps Days Tokyoの許可を得て、記事掲載しています。

連載：DXにおけるDevSecOpsとは？

「DevSecOps Days Tokyo」レポート①：「米・国防総省はどのようにしてKubernetesとIstioへの移行を果たしたか？
「DevSecOps Days Tokyo」レポート②：「DevSecOpsの導入を成功させるための5つのチャレンジ」
「DevSecOps Days Tokyo」レポート③（前編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート③（後編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート④：「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」