メルマガ登録
ベストなDXへの入り口が見つかるメディア
-
テーマから探す
-
技術から探す
-
業界・事例から探す
-
関連トレンドから探す
ベストなDXへの入り口が見つかるメディア
テーマから探す
技術から探す
業界・事例から探す
関連トレンドから探す
DX時代において、業務システムは改革の対象の一つとなっています。業務にマッチしたシステムを構築する必要性から、開発と運用がダイナミックに連携し、改善を繰り返す 開発手法である「DevOps」が浸透しつつあります。
しかし、DevOpsで実現される高速開発と高頻度のリリースを、従来型のセキュリティ対策だけで守りきるのは困難です。そこで、DevOpsにセキュリティを融合させた「DevSecOps」の重要性に注目が集まっています。
2020年10月5日と6日、「DevSecOps Days Tokyo」（主催・DevSecOps Days Tokyoコミュニティ、後援・アメリカ大使館・経済産業省・カーネギーメロン大学CyLab、SEIほか）がオンラインにて開催されました。
DevSecOpsDaysとは、米・カーネギーメロン大学や先端テクノロジー企業の有志によって始められた、DevSecOpsについての情報交換を行うコミュニティイベントです。2020年には東京の他、サンフランシスコやロンドン、シンガポールなど、合わせて世界12都市で開催。
DevSecOpsをテーマにしたイベントが日本で開催されるのは初めてであり、米・国防総省やカーネギーメロン大学関係者が登壇することで注目を集めました。
ここでは、DevSecOps Day Tokyoを4回に分けて、スペシャルレポート。今回は、株式会社ブレインパッドの韮原祐介氏の講演「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」の内容をレポートします。
「DevSecOps Days Tokyo」レポート①はこちらからお読みいただけます。
「DevSecOps Days Tokyo」レポート②はこちらからお読みいただけます。
※本記事は、ブレインパッドがDevSecOps Days Tokyoの許可を得たうえで、本イベントを聴講し執筆しています。細心の注意を払って情報を掲載していますが、そのコンテンツの誤謬・遅延・正確性・相当性・完全性などについて一切責任を負いかねますのでご了承ください。
イベントの模様はYouTubeに公開されています。
・Day1：https://www.youtube.com/watch?v=poMiLi0kS88&t=5689s
・Day2：https://www.youtube.com/watch?v=DOaWf2aKFwg&t=1867s
ここからは、AIのサイバーリスクについてジェネラルに考えていきます。AIに限らずあらゆるシステムや人間の情報処理は、何かを入力し、情報処理し、出力するというステップを踏みます。このどの部分を攻撃してもハックできてしまうのです。
入力をハックされた例を一つ挙げると、マイクロソフトの作ったチャットボットにユーザーがゴミのデータを学習させていった結果、差別発言をするようになり、サービス自体を停止したということがあります。あとは学習済みモデル自体もハックできます。一時停止の標識にテープを貼ると、AIはこれを一時停止ではなく、速度制限の標識だと判断してしまうという。実際に運転アシスト機能で、標識を認識する機能が最新の車には搭載されていますが、あるラーメン屋さんのチェーン店の看板ロゴが進入禁止の標識だと誤認識したという例があります。これはハックしようとしたケースというよりはバグが見つかったケースです。これを意図してやることも当然できるわけです。
上記、左と右に車の写真があり、人間にはどちらも車に見えるのですが、右の写真にはあるノイズを入れているんです。ノイズを入れた結果、右の写真をAIはダチョウだと判断しました。人間には全然ダチョウに見えないのですが、AIは人間と同じような認知の仕組みをとっているわけではないので、こういうミスが起きます。
さらに、ノイズをいっぱい加えなくとも、1ピクセルだけいじることで、認識結果が変わることがあります。鹿の写真をいじって1ピクセルだけ白にしただけで、AIが85.3%は飛行機でしょうと判断をしたのです。これを1ピクセルアタックと呼びますが、こういうこともできてしまうのです。
さらに、AIが出してきた結果そのものを書き換えてしまえるという問題もあります。このように考えると、いつどのように狙われるか分かりません。
最後に、日本流のDevSecOpsをどう実現していくのかについても考えなければなりません。アメリカから教わった方法を日本で導入しようとしても、状況は異なります。例えば、ソフトウェア開発に従事する技術者が社内にいるのか、社外にいるのかということです。アメリカは72%と、ほとんどが社内技術者で、3割ほどが社外の技術者です。一方の日本は、社内技術者はわずか25%で、残りの75%は社外技術者なのです。
このため、日本でユーザー企業側がどのようにソフトウェア開発に関わっているかというと、ほぼペーパーワークといえます。ソフトウェア開発のプロセスにユーザーが入っているようで入っていない。ソフトウェアの中身がブラックボックス化しています。例えば、オープンソースをスキャンして脆弱性が見つかったらバージョンをアップするような便利なツールはありますが、今のままだとSIerがやりたがらない。
「あれ、なんでSIerさんはこんな脆弱性の高いコードをほったらかしていたんですか？」という責任問題になって、面倒なことになるので、SIerがやろうという意欲が湧かない状態になっています。
これが日本経済全体の脅威なのではないでしょうか。ソフトウェア開発の競争力自体が経済競争力の源泉となっているにもかかわらず、手持ちのシステムはベンダーロックインされたブラックボックス状態です。グローバル企業においては、当然グローバル競争市場で敗北し、日本経済を支える基幹産業が衰退しかねない状況なのです。
これについて私は、自前でシステムを作っていくしかないと思っています。基本的なアーキテクチャを社内でデザインし、それを作る指示やコードレベルでクオリティチェックができる人材を採用・育成すべきでしょう。
完成されたシステムに対してお金を払うのではなく、純粋にエンジニアリソースにお金を払う。そして、システム開発アーキテクチャをマイクロサービス化し、全体システムの中の重要なモジュールは内製化して、他は外部企業とコラボしながら作っていきます。これはベンダーロックインを排除し、ソフトウェアライフサイクルを早く回す上で重要なことでしょう。
結局、自分たちで責任を持って作るしかありません。
クライアントの経営のために、これからはSIerはクライアントの内製化支援をしていくべきではないかと私は思っていますが、事業構造を変えるのはなかなか難しいかもしれません。この点、ベンチャー企業や若手の方々に期待しています。DevSecOpsが前提となるようなクラウド・ネイティブで、コンテナを使い、コンテナオーケストレーションにKubernatesを使い、マイクロサービス・アーキテクチャを採用する…といったように新技術をフル活用し、自前でシステムを作るような会社に移って腕を磨く。これは必ず今後のスキルにも生きてくるでしょう。あるいは、内製化を支援するベンチャー企業を興してもいいと思います。
日本流のDevSecOpsの本丸というのは結局、18兆円あるITおよびシステム開発業界全体の産業構造の変革だと私は考えています。一歩目はやはりDevSecOpsについて十分な知識を浸透させ、知見を共有することです。いかにして日本企業が産業競争力を維持するかについて、現在のSIerと企業の間の付き合い方に潜んだ構造的な問題を直していくべきでしょう。
※本記事は、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：これまでとこれから」
この記事の続きはこちら
連載：DXにおけるDevSecOpsとは？「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」 「DevSecOps Days Tokyo」レポート④
