コンテナ・DevOps時代のセキュア開発を問う――セキュリティバイデザインがもう避けては通れない理由：特集：継続的に儲けるための「セキュリティバイデザイン」入門（4）

クラウドやコンテナ、マイクロサービスが主流になりつつある現在、セキュリティバイデザインという考え方をどのように発展させ、適用させていけばいいのだろうか。

[高橋睦美，＠IT]

　仕様策定・設計時からセキュリティを考慮する「セキュリティバイデザイン」という考え方は、ウオーターフォールが主流の時代から既に注目されていた。

笹原英司氏

　時は流れ、システム開発の流れは大きく変化しつつある。今やデジタルトランスフォーメーションの実現を視野に入れ、さまざまな企業でアジャイル開発やDevOpsといった開発スタイルが広がってきた。これとともにインフラ基盤も、オンプレミスのサーバから、クラウドやコンテナ、マイクロサービスへと、その主流が変わりつつある。

　こうした新しい環境を前に、セキュリティバイデザインという考え方をどのように発展させ、適用させていけばいいのだろうか。医療・ライフサイエンス業界のセキュリティやガバナンスに広い知見を持ち、クラウドセキュリティアライアンス（CSA）などの業界団体でも活動する笹原英司氏に尋ねた。

DevとOpsのエコシステムを前提にセキュリティバイデザインの検討を

　コンテナ環境やマイクロサービスを前提としたアプリケーション開発には、セキュリティ面でどのような課題があり、どう進めていけばいいのか――これはグローバル共通の問題意識だ。笹原氏によると、NIST（米国立標準技術研究所）が包括的なガイドラインを定めている他、CSAやOWASP（Open Web Application Security Project）といった業界団体でも、より踏み込んだ具体的なガイダンスをまとめている最中だという。

　ここでポイントになるのは、DevOpsやDevSecOpsという考え方だ。「今までの開発では開発者（Dev）と運用管理者（Ops）が別々だったが、今や、DevとOpsのエコシステムを前提に、コンテナやマイクロサービスを使う形となっている。必然的に、DevだけではなくOpsもいるという前提に立ってセキュリティバイデザインを考えていかなくてはならない」（笹原氏）

　例えば、「システムに脆弱（ぜいじゃく）性が見つかった場合にどのように対応するか」「インシデント対応にどう備えるか」といった部分は、これまで主にOps側の課題だったが、それが変わってくるという。「金融機関のように24時間動かし続けなければならないシステムで『どのタイミングでパッチを当てるか』といった事柄を解決するには、OpsだけではなくDevもコミットしなければならない」（笹原氏）

　また、これまでセキュリティバイデザインという言葉は、開発終了後のテスト段階、あるいはリリース後に脆弱性が発覚すると、設計段階で対応した場合に比べコストが何十倍、何百倍にも膨らむという文脈で語られることが多かった。もちろんこうした観点も重要だが、エコシステム全体を見据えた視点から捉えていく必要があるという。

　「ドキュメントをちゃんと作成する、ログを残すといった具合にやるべきことは変わらないけれども、その先にOpsやユーザーがいることを想定し、きちんとインパクト分析を行い、大きく広がる対象を把握した上で取り組まなければならない」（笹原氏）

　そして、もう一つ必要になってくる役割が「アーキテクト」だ。「システム開発の内製化と並行してDevSecOpsやアジャイルに取り組む際、世界のさまざまなガイドラインの動向を踏まえて全体を見る役割が必要だ。マイクロサービスの世界になってくると、DevとOpsに加え、全体を俯瞰（ふかん）して見るアーキテクトが求められる。アーキテクトがちゃんと全体設計を行った上で、DevやOpsがそれぞれの役割を果たしていくことになるだろう」（笹原氏）

さまざまなサービスをつなぐ「API」が攻撃のターゲットに

　では、新しい環境でのセキュリティバイデザインに取り組む上で、具体的に留意すべきポイントはどこだろうか。笹原氏は、変化に伴って留意すべき点として「API」を挙げた。「今、一番狙われているのはAPIだ。ダイレクトにAPIを狙ってくるサイバー攻撃が増えている」（笹原氏）

　例えばアカマイ・テクノロジーズが公表した「インターネットの現状」レポートでは、金融サービスのAPIを狙い、資格情報（クレデンシャル）を盗み取ろうとする攻撃のリスクが指摘されていた。仮に資格情報を詐取されてしまうと、関連するマイクロサービスに簡単に入り込めてしまうことになる。

　笹原氏はこうした背景に触れ、「クレデンシャルを乗っ取って、そこから入り込んでいく攻撃が増えている。金融サービスに限らず、マイクロサービスやコンテナといったものは全てAPI経由でつながるため、そういうところが必ず狙われる。基本的なメールセキュリティとID管理を徹底した上で、DevSecOpsやコンテナセキュリティを検討すべきだ」と指摘した。

マイクロサービスセキュリティのガイドライン（「アプリケーションコンテナ／マイクロサービスのセキュリティ概説」から引用）

　もう一つ注意が必要なのは、インフラ基盤の変化。具体的にはクラウド採用に伴う責任の所在だ。「AWS（Amazon Web Services）やGCP（Google Cloud Platform）といったクラウド基盤は、責任共有モデルに基づいている。彼らが責任を持つ部分はがちがちに対策してあっても、アプリケーションのところはユーザー企業が責任を持たなければならない。従来のオンプレミス環境ではベンダーとの間で責任をあいまいにしている部分もあったが、それをクリアにしないといけない」（笹原氏）

　コンテナやサーバレスのセキュリティを巡る標準やガイドラインは日々更新されていくため、利用する側はもちろん、クラウドサービスを提供する側も追い付くのに精いっぱいという状況だ。それでも、「それぞれの責任分界点をはっきり踏まえた上で、何をどこまでやるべきなのかを最初の契約時にしっかり確認する必要がある」（笹原氏）とした。

コンテナセキュリティのガイドライン（「アプリケーションコンテナ／マイクロサービスのセキュリティ概説」から引用）

セキュリティバイデザインがもう避けては通れない理由

　こう考えてみると面倒な側面もあるセキュリティバイデザインだが、この先、企業はこの取り組みを避けては通れない。というのも、各種法規制やガイドラインによってセキュリティバイデザイン、さらには「プライバシーバイデザイン」という考え方が、何らかの製品を販売し、調達する際の必須条件として求められつつあるからだ。

　「こうした取り組みをしないと、端的に言えば製品を買ってもらえない、お金にならないということになる」（笹原氏）

　特にユニークなのはヨーロッパの動きだ。「これまでの認証は、製品・プロダクトに対する認証だったが、これからはソフトウェアを開発する企業の文化を問い、その文化の中にセキュリティバイデザインが根付いているかどうかといった組織に対する認証に変わっていくため、Devに対する影響も大きくなるだろう」と笹原氏は述べ、現場の開発者や運用担当者だけではなく、トップも巻き込んだ取り組みが必要だとした。

　これはまた、サプライチェーン全体にまたがるセキュリティチェックが必要になることも意味する。APIの参照先やDockerイメージのセキュリティチェックといったレベルにとどまらず、「アプリケーション開発者や企業をちゃんと評価しないといけないし、ひいては、自分たちが使っているサプライヤーがきちんとセキュリティバイデザインやプライバシーバイデザインを実践しているかどうかもチェックしないといけない」（笹原氏）

調達条件に含まれるセキュリティバイデザイン、先行事例を参考に対応を

　こう考えていくとセキュリティバイデザインはハードルが高く思えるが、既にそれを実践し始めている先行事例もある。特に参考になりそうなのが、医療機器の分野だ。

　「医療機器の場合、販売に当たって厚生労働省に申請する際、セキュリティバイデザインを前提にしている。開発に当たって実施したことを全部ドキュメントに残し、かつSBOM（ソフトウェア部品表）を実践することが求められている。また、機器の申請が通って保険適用対象になり、販売された後も、そうした情報を当局に出しておくことで、脆弱性が見つかった場合は病院とメーカー、当局で脆弱性情報を共有し、それをベースに追いかけていく流れになっている」（笹原氏）

　機器に限らず、アプリケーションを導入する際にも同様に、セキュリティバイデザインを実施しているかどうかが調達基準に含まれているという。特にイギリスのNHS（国民保険サービス）では、「イギリスの病院が使うアプリケーションやAPIに関しては全てNHSがチェックする。ペネトレーションテストを行ってOKだったものが専用のマーケットプレースに用意され、それらを自由に使う仕組みができている」と笹原氏は説明した。

　似た流れが、FinTechや金融、製造業にも広がりつつあり、それを裏付ける法規制も着々と整備されている。「例えば金融の場合は、ニューヨーク州金融サービス局がサイバーセキュリティガイドラインを出しており、その中に、はっきりとセキュリティバイデザインが盛り込まれている」そうだ。

　しかも、スコープは開発プロセスだけに限らない。インシデント対応についても、情報漏えいなどの事故発生時にどのように情報を開示するか、CSIRT（Computer Security Incident Response Team）とPSIRT（Product Security Incident Response Team）がどのように連携しながら対応すべきかといった事柄についてもガイドラインが整備されつつあるし、カリフォルニア州のようにプライバシーやIoTのセキュリティに関する法規制を整える地域が出てきた。

　医療機器や製造業といった“ものづくり”の分野は、セーフティに関しては多くの知見を持っているが、セキュリティとなると未消化の領域であるのも事実だ。また、ITとOTでは、ライフサイクルをはじめ、さまざまな違いがある。セキュリティを取り入れるに当たって参考になるのが「先行事例」や「ベストプラクティス」だ。特に、Volkswagen（フォルクスワーゲン）やRobert Bosch（ボッシュ）、あるいはDeutsche Bank（ドイツ銀行）といった企業が積極的に自分たちの取り組みを公表しているという。

　また、灯台下暗しだが、笹原氏によると「実は、日本企業の海外法人の方がこういった取り組みは進んでいる」という。自動車メーカーの海外子会社の中には、海外のPSIRTが本社のCSIRTと連携しながらセキュリティバイデザインに取り組んでいる例があるそうだ。もしかすると、自社でも既に、海外支社が多くの知見を持っているかもしれない。

共通化し、全体のアーキテクチャを見据えることがポイントに

　最後に、コンテナやマイクロサービスを前提にしたセキュリティバイデザインに取り組む上で重要なポイントとして、笹原氏は「要件に対して一つ一つ個別に対応するのは絶対無理なので、なるべく共通化して対応していくことだ。そして、全体のアーキテクチャ設計やフレームワークが必要だ」とした。

　同時に、セキュリティは、ある日突然ブレークスルーが訪れる性質のものではない。技術に対する既存のナレッジにプラスαをしながら追い付いていくものだという。「既存のオンプレミスシステム、例えば基幹系システムやデータベースといった、これまでの技術を知っている技術者のキャリアが、新しいインターネット系のDevとの橋渡し役として役立つだろう」（笹原氏）

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

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

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