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

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

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

笹原英司氏

　時は流れ、システム開発の流れは大きく変化しつつある。今やデジタルトランスフォーメーションの実現を視野に入れ、さまざまな企業でアジャイル開発や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）といったクラウド基盤は、責任共有モデルに基づいている。彼らが責任を持つ部分はがちがちに対策してあっても、アプリケーションのところはユーザー企業が責任を持たなければならない。従来のオンプレミス環境ではベンダーとの間で責任をあいまいにしている部分もあったが、それをクリアにしないといけない」（笹原氏）

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

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

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