DX時代の今、経営層やエンジニアに問い直す、「セキュリティ対策」と「セキュリティバイデザイン」の意義とは：特集：継続的に儲けるための「セキュリティバイデザイン」入門（1）

近年の複雑化、多様化するサイバー攻撃を迎え撃つセキュリティ対策は、迅速なサイクルを回す開発が求められるデジタルトランスフォーメーション（DX）の阻害要因になるのではという意見もある。その中、DXとセキュリティの両立に有効なのが「セキュリティバイデザイン」だ。では、企業がセキュリティバイデザインに取り組む上で、どのような課題があるのか。

[高橋睦美，＠IT]

　デジタルテクノロジーをあらゆる業務に活用し、生産性や創造性を向上させ、自社の価値を高めていくデジタルトランスフォーメーション（DX）の流れが確実に広がっている。だが、DXに向けて迅速に開発サイクルを回す上で、セキュリティ対策は阻害要因になっているのではないか――＠ITの記事では時々こうしたテーマを提示してきた。

　だがアスタリスク・リサーチ CEOの岡田良太郎氏は、一連の話の所々に「異議」があるという。そもそもDXの本質とは何か、その中でセキュリティはどのように織り込まれていくべきか、そしてDX時代のセキュリティバイデザイン（SBD）はどのような形になっていくのかなどについて、岡田氏に尋ねた。

「うちもDX頑張っています」言いたいだけ症候群？

――今、国内のユーザー企業にDXが求められる「背景」について教えてください。「DXレポート」にあるような「2025年の崖」問題、もしくは、デジタルディスラプションなどでしょうか？

アスタリスク・リサーチ CEOの岡田良太郎氏

岡田氏　レガシーシステムを捨てて、いろいろなものをペーパーレス化し、プロセスも変えることによって、これまでのボトルネックをなくして物事がクリアに進むようになる。逆に、昔と一緒のやり方を続けてきたばかりに、急に市場に参入してきた他社との競争に負けてしまう。そうした事態を避けるために、リスクを取ってでもデジタル化していかないといけない――それが最近言われているDXです。

　このトレンドを最初にけん引してきたのは、自社の戦略に基づいて「このボトルネックを解消したい」といった強い問題意識を持ち、既存の組織やプロセスをぶっ壊してでも実現したいと思っている企業ですね。

　けれど、今それに続いているのは、そういうのを横目で見て「おいおい、うちもうかうかしていられないぞ」「あれをやるには何をしたらいいんですか、誰か引き抜けませんか」という具合に、何を目標にするのかが空洞のままツールとポーズだけまねしている、そんな企業もあるんじゃないかなと思います。DX担当役員も置かず、情シスに任せるだけではうまくいくはずもありません。

　例えば「今まで数日かかっていたことを数分、数秒にしたい」といった明確な目標や戦略がないまま、今やっている方法をそのままコピーしてクラウドに持っていっただけ。例えば「わが社もオンプレからクラウドにしました！　DXを頑張っています！」と言いたいだけなんじゃないかと。

　及川卓也さんが『ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略』（日経BP）でも述べられている通り、DXとはデジタル技術を利用した変革のことであって、単にアナログなものをデジタル化して多少見てくれが良くなる程度の話ではありません。私は、DX戦略は事業の「スピード」「連携性」そして「可視化」、この3つに集約できると思います。新しい技術やツールをうまく活用することによって、この3つの戦略が実現しやすくなる、そこが肝心なところだと思います。なのに経営層は、こうした手だてを社内に取り入れることで「どんな事業上のメリットがあるのか」「どんな戦略を満たすのか」といった事柄がマッピングできていないんじゃないでしょうか。

DXを阻害するのは既存のシステムではなく、既存の体制

――経済産業省が出したDXレポートについて、どのように見ていますか？

岡田氏　DXレポートを読むといろいろ面白いことが書いてあるし、よくできているなと思うんですが、気になるのは「ボトルネックがあるのはシステムのせい。今あるシステムがダメだからDXが進まないんだ」という具合に書いてあるところです。

　けれど、それはDXの本質ではありません。「成長の阻害要因の解消」「成長に向けた新機軸の導入」など、事業側の戦略こそが本質であり、それがあって初めて「現状のシステムは、こういうアーキテクチャになるべきだ」という話になります。システムの乗り換えとDXをごちゃ混ぜにしていいのかと、ちょっと疑問に思います。

　「セキュリティ対策システム」を例に、レガシーシステムの刷新について考えてみましょう。例えば今までの「ファイアウォールに守られたLAN」というシステムをモダンなアーキテクチャに変えようと思うと、まず「LAN」という存在をなくすことから始まります。代わりに防御の要になるのは「認証」基盤です。自宅にいても会社にいても、何らかのITリソースにアクセスするには必ず認証を受け、その上でしかるべきリソースにアクセスして仕事をするという姿です。

　つまり、1990年代から2000年代くらいにかけて構築してきた「社内のネットワークは安全だ」という前提に立って構築した仕組みを捨てて、認証基盤を使う仕組みに乗り換える必要があります。これを実現するには、「ファイアウォールで守られていたら大丈夫だ」という考え方を改める必要があります。

　そのとき阻害要因になりがちなのは、既存のシステムを構築しメンテナンスしてきた情シス部門や、それを支援してきた役員の「プライド」だったりします。阻害要因があるとすれば、レガシーなシステムそれ自体よりも、既存の体制の、中でも“変化”に同意しない人たちでしょう。

丸投げから共同、協調に、重厚な計画から柔軟な変化に

――「変化に同意しない人たち」というのは「リスクを取ることを恐れる人たち」ともいわれますね。

岡田氏　これまでの伝統的なリスク回避方法は「慎重であること」でした。けれど今のリスク回避の仕方は「迅速かつ柔軟であること」です。間違ったらできるだけ早く訂正することでリスクを回避するわけです。

　過去、慎重であることによってリスクが回避できたのは、周りのスピードも、コンシューマーの声が会社に届くスピードも、頑張りが業績に反映されるスピードも遅かったからです。その慎重さによって、浅はかな進め方を邪魔することにより、きっちり開発することができました。

　けれど今は、慎重に開発を進めたところで、リリースしたときにはもう状況が変わっています。やり直しや切り戻しを許容できないほど、スピードのプレッシャーが高まっています。

　ですから今は、迅速な意思決定、迅速なプロトタイピングでとにかくドラフトを出し、ラフコンセンサスをとって開発を進め、おかしければすぐ直すことでリスクを回避すべきなんです。いわゆるPDCA（Plan→Do→Check→Act）サイクルからOODA（Observe→Orient→Decide→Act）サイクルへの移行が求められていると思いますね。

OODAサイクル（出典：アスタリスク・リサーチ）

　今起きている事柄を観察し、「何がボトルネックになっているか」「何が見えていないため機会損失が起きているのか」といった分析をかけて、その問題を解消するためにリソースを投入し、「実施した結果、状況はどうなったのか」を観察する。これに最もフィットするシステムを構築するのは、会社が主体的な戦略さえ持っていれば、重厚長大なプランを立てて、SIerを呼びつけなくても、割と小さなチームでできるはずなんです。小さくチームを組んで、今ある課題を特定して、リーダーシップをとりながらアジャイルを回す方がフィットすると思います。

　なので、僕がちょっと思っているのが、実は再び「アジャイルブーム」が来ようとしているのではないかということです。

　今から10年くらい前にも、みんながアジャイル、アジャイルって言っていた時期がありましたが、あんまりうまくいかなかったですよね。けれど、今は何が違うかというと、PaaSがあり、FaaSがあり、サーバレスがある。ポチポチっと入力するだけでシステム基盤が整備され、何かが動く。こうした技術の進歩のおかげで、アジャイルの方法論で進めても、1週間くらいのスプリントの中で形や成果が出せるようになってきました。自由に適切な技術を選択しやすくなりました。

　その中で経営、企画、開発に求められる役割を考えるわけですが、経営はやはり「いかに目標を持つか」が大事になります。「どんな阻害要因を取り除きたいのか」「どのボトルネックを解消したいのか」「何を可視化したいのか」「何と何を連携させたいか」を決めるわけです。企画側は、それらにプライオリティを付け、さらに仮説を立ててモニタリングしていくという、仮説検証の責任を負います。そして開発にとっては、それを実現する道具をいかに柔軟に扱えるようにするかが鍵になってきます。

　システム構築を、丸投げスタイルからアジャイルによる協働、協調に。重過ぎる要件定義や設計よりも、段階的な開発サイクルに、という具合にシフトする必要があるということです。

「デザイン」の変容に伴う「セキュリティバイデザイン」の変化

――その経営、企画、開発から敬遠されがちだったのがセキュリティ対策であり、「迅速なサイクルを回す開発が求められるDXの阻害要因になるのでは」という意見もありますが、いかがでしょうか。企業がSBDに取り組む際の課題について教えてください。

岡田氏　その意見は、DXやアジャイルが求められる今は真逆ですよね。迅速なサイクルを回せるからこそ、セキュリティ対策はやりやすくなるんです。

　従来のやり方であれば、ある程度システムができた後から「この情報は暗号化していないとダメ」と言われて、「え、もう一度やり直すんですか」となっていたのが、今や、暗号化オプションをポチッと押して、APIを通せばできるんですから。CI（Continuous Integration）が浸透してきているので、インテグレーションが継続的である以上、セキュリティ対策も継続的にできるはずなんですよ。

　だから、そもそものSBDの意味である「設計段階でセキュリティを意識すべきである」ことについては、DX時代に合わせるとちょっと違うなと思います。

　いや、もちろん「設計段階でセキュリティを意識すべき」というのはその通りですが、これだけリファクタリングがやりやすくなり、基盤が柔軟に構築できる時代になると、「デザイン」つまり「設計」というものの意味も変わってくると思います。

　現在は前述の通り、短期間で内製することができ、フレキシビリティがあれば、自分たちの体制の中にインプリしやすいはずです。となると、何か問題があっても見つけやすく、直しやすいということが、サービス全体の設計の必須条件になってきていると思います。つまり、これから求められる「DX時代のSBDにおけるデザイン」とは何かを考えると、「グランドデザイン」になるはずです。そもそもDXは1つのシステム／サービスで実現するものではありませんよね。

――よくいわれるのが、大きなモノリシックのサービスではなく、修正、改善の影響範囲を小さくして、デリバリーのスピードを上げるマイクロサービスのアーキテクチャがDXには求められるということですね。たくさんのアプリケーションコンテナに乗せられたマイクロサービスがAPIで相互に連携して1つのサービスを形成することで、モニタリングや障害箇所の特定、全体の復旧が難しくなるともいわれます。

岡田氏　ですからSBDも、例えば「個別のサービスにおけるSQLインジェクションを防ぐこと」という意味合いではなく、「どこかから情報を盗もうとしても気が付く」「どこかが落ちてもサービス全体は死なない」といった具合に、全体の構造として、チームとして企業の事業を守る仕組みをデザインする。「事業成長や顧客満足、スピードなどを保証できるようなシステム構成になっているか」といった事柄も考えないといけない。これはエンジニアの問題ではなく経営の問題、事業戦略の問題ですよね。

　「グランドデザインの中でどのようにセキュリティ対策を柔軟に変えたり、強化したりできるのか」「ビジネスを守るためのセキュリティが、適切なコストとスピードで、どのような構造で配分されていくか」が大事になると思います。何か特定の製品を入れることを「セキュリティ対策」というのではなく、「どのような脅威があるのか」を認識し、その脅威が発生したことを検知し、対応し、復旧、持続させるためのアーキテクチャを考える必要があるでしょう。

　また運用の中で、「どんな問題が起きているか」をモニタリングできることも、DXでは重要です。状況を可視化して「何か問題があれば、どう対応するのか」を考えてデザインし、実装し、検証し、デリバリーしていく。そういうDevとOpsのループを実装するときに、システム上の、あるいは承認プロセスのような組織上のボトルネックをなくしていくのがDXということですよね。

DevとOpsのループ（出典：アスタリスク・リサーチ）

――今までの開発では、ウオーターフォール一辺倒だったので、SBDにおいても「最初にセキュアな設計やアーキテクチャをやらないといけない」ことが、利点ではなく“課題”になってしまい、経営、企画、開発から敬遠されがちだったのかもしれません。もともと、セキュリティについて意識するのは、大きな事件や事故がきっかけになることがほとんどでしょうし。

岡田氏　「完璧なセキュリティ」はあり得ないでしょうが、あるとすれば、それは「ミス（事件や事故）のないセキュリティ」のことではない。必要とされるのは、アジリティ。「どれだけ変化に対応する力が高いか」が重要であり、段階的、継続的にリスクやインシデントに対応していけること。レジリエンスですね。これこそ「完璧なセキュリティ」として目指すべき姿だと思います。

不要なものをそぎ落とすDXはセキュリティ見直しのトリガーにも

――セキュリティとDXの両立に向けて、企業は何から手を付けていけばいいのかを教えてください。

岡田氏　DXという言葉は、「パンドラの箱」なんですよ。今まで面倒くさいから誰かのせいにしていたり、あるいは見ないことにしていたりしていたいろいろな事柄を、ちゃんと見て扱っていく。自社に内在するリスクを明らかにし、棚卸しをしっかりやって不正ができないようにしていく。いわば「やり直し」にちょうどいいトリガーになると思いますよ。例えば現実世界でも、引っ越しをやるたびに不要なものは捨てられますよね。必要なものが何かを再認識し、新しいアーキテクチャに変わります。DXをきっかけにセキュリティの見直しも進むんじゃないでしょうか。

　逆に失敗しがちなのは、今までのやり方をそのままトランスポートすることです。デジタルトランスフォーメーションではなく、デジタルトランスポーテーションはダメですよね。

　本当に必要な機能は何か、サービスは何かを突き詰めて、不要なものを削ぎ落とした結果、スピードと可視性が高まる。それが新製品開発を促進することは間違いないでしょう。そういう意味でも、今こそ企業はアジリティを身に付けるべきタイミングだと思います。

　DXやDevOpsなど、アジリティの高い動きの中で、よくあるセキュリティサービスはふるい落とされちゃうかもしれません。むしろ、ふるい落とされるべきかもしれませんね。なんせ、脆弱（ぜいじゃく）性を見つけてもすぐに直せるアジリティを企業が持つことになったら、脆弱性を見つけることそれだけの価値って激減するんじゃないかなと思います。どうすればスピーディーに欠陥を改善できる仕組みにできるか、ということが主戦場ですから。

――個人としてはいかがでしょうか。エンジニアと経営者それぞれの視点から教えてください。

岡田氏　DXが進んでいくと、これまでのように「人格や人当たり、コネなんてのがあって初めて経営がうまくいく」という泥臭いビジネスシーンは、もっとドライに、スピーディーに、合理的なサービスが選択しやすくなり、ひいてはそういう優れたサービスだけが生き残ることになる。つまり、ものの売り方とニーズの捉え方、さらにオンラインコミュニケーションに長けていれば、誰でもビジネスができちゃうようになるんじゃないでしょうか。

　一方で、経営者が必要な技術を習得するハードルも下がっています。10年くらい前は、「経営者が技術を学ぶ」といっても複雑過ぎて困難だった。でも今は、クラウドで容易にサービスが立ち上げられます。機械学習やデータ解析など、新しい技術を学ぶ機会は拡がっており、コストも下がっています。経営者や事業部門、はたまたジャーナリストのような非技術者のITへの関心は熱いですよ。そういう方々から「最近集中してエンジニアリングを学んだ」なんて話もよく聞くようになりました。

　エンジニアも、既存の知識の上でぼーっと生きていたらまずい。経営者が技術を勉強するのと同様、エンジニアが経営を勉強するのも、ぜひお勧めしたいですね。スピードが上がりますから。

――DevとSecとOpsという「エンジニア」同士だけではなく、ビジネス／企画との連携が求められるDXによって、縦割りの組織で役割が明確化／サイロ化されている時代が終わっていくとすると、企業全体を見渡せるように経営も勉強しないといけなくなるのではないでしょうか、ということですね。ありがとうございました。

特集：継続的に儲けるための「セキュリティバイデザイン」入門

デジタルテクノロジーをあらゆる業務に活用して生産性や創造性を向上させ、自社の価値を高めていくDX（デジタルトランスフォーメーション）の流れが確実に広がっている。一方で、デジタルディスラプションの焦りから短絡的なサービス開発に走った結果が、昨今の報道を賑わし始めている。せっかく開発したデジタルサービスが、脆弱性を残していて情報漏えいを起こしたり、ユーザーのプライバシーを侵したりするようなものでは、自社の価値を下げ、大きな損害を生む結果になっているのは周知の通りだ。近年の複雑化、多様化するサイバー攻撃を迎え撃つセキュリティ対策は、迅速なサイクルを回す開発が求められるDXの阻害要因になるのではという意見もある。その中、DXとセキュリティの両立に有効なのが「セキュリティバイデザイン」だ。では、企業がセキュリティバイデザインに取り組む上で、どのような課題があるのか。コンテナ、マイクロサービス、サーバレス、そしてアジャイル／DevOpsといった、DX時代に求められる技術や手法を駆使した現在の開発では、どのようなセキュリティバイデザインが求められるのか――技術面を中心に、継続的にもうけるための「セキュリティバイデザイン」の入り口を紹介する。

特集：継続的に儲けるための「セキュリティバイデザイン」入門