「恐らく、こうしたチームの孤立状態が最も大きな問題になる。DevSecOpsは、セキュリティチームと製造チームが連携し、対立しないで業務を進めることを目指す考え方だ。こうした点からもチームの孤立状態は課題になる。そのため、重要なのはDevSecOpsという方法論を検討することだ」（バラガンスキ氏）

　問題は、DevSecOpsを実践している企業がごくわずかしかないことにある。新しいアプリケーションを可能な限り迅速に運用環境にリリースすることを重視し、セキュリティの問題には後から対処できると考えている企業はまだ多いと同氏は指摘する。

　問題の中心には、マイクロサービスの設計方法が一つではないことがある。異なる環境で実行され、異なる通信チャネルを使用し、異なるプログラム言語で記述された複数のマイクロサービスを集めて一つのアプリケーションにできる。

　「この設計方法により、アプリケーションを構成する他のコンポーネントとは切り離して、簡単にマイクロサービスを開発、導入、デバッグ、保守、運用できるようになる。だが、さまざまなレベルで複雑さが生まれることになる」（バラガンスキ氏）

　「その複雑さは分散され、モノリシック開発チームほど顕著にはならないため、見過ごされがちになる。その結果、マイクロサービスアーキテクチャでは、一般的な仮想マシンやコンテナなど、低レベルのインフラのセキュリティには十分な注意が払われない」と同氏は付け加える。

　フレームワーク開発スタックそれぞれが独自の問題を抱えていることが、セキュリティを一層複雑にするとして、同氏は次のように述べる。「その上、マイクロサービス同士がコミュニケーションに使うAPIや、APIの代わりに使うメッセージングプロトコルもあり、そのそれぞれがセキュリティについて独自の課題を抱えている」

　何よりも、コントロールプレーンやサービスメッシュの各レイヤーに複数の種類があることが問題だ。こうした機能によって、ネットワーク経由でのサービス間の通信が制御され、セキュリティが確保された通信、サービス検出、負荷分散などの基本機能が自動化される。

　「そのため、多くのレベルでこうした膨大で新しい複雑さを抱えることになる。とはいえ、多くの担当者（特に開発者）は、ある程度は自助整理されていくだろうと考えがちだ。だがほとんどの場合、この複雑さを全体的に考えている担当者がいないのが現実だ」（バラガンスキ氏）

　「開発者、セキュリティの専門家、運用担当者、コンプライアンスの責任者は誰もが、自身が注力すべき分野を抱えている。だが大きな視点で全体像を見ている担当者はいないことが多い。これが恐らく最も大きな問題になる。というのも、一方では新たなレベルの複雑さを抱えているのに、他方ではシステム全体の可視性が完全に失われているためだ」

　マイクロサービスのセキュリティにすぐに取り掛かる必要がある。だがこれは難しい課題だ。マイクロサービスの設計、導入、保守には、確立された設計パターン、ベストプラクティス、標準がほぼないに等しいためだとバラガンスキ氏は指摘する。

　「まずは、これまで認識していなかった問題の存在に気付くことだ。その上で、適切な疑問を投げ掛けてその答えを模索し始める必要がある。問題を認識しない限り、解決策を探ることもできないだろう」と同氏は話す。

　マイクロサービスの仕組みの基本と、このアーキテクチャを使用する場合のセキュリティへの影響を理解することから着手することを同氏は推奨する。「基本を知らなければ、情報に基づくリスク評価を基礎として綿密な戦略を立てることはできない」と同氏は言う。

　「問い掛ける疑問を見つけるには、NIST（米国立標準技術研究所）が草案を作成したSP（Special Publication）『Security Strategies for Microservices-based Application Systems』（マイクロサービスベースのアプリケーションシステム向けのセキュリティ戦略）を確認するといい。この草案には、基本的に考慮が必要な事項の一覧が掲載されている」

　この草案には、マイクロサービスに関連するセキュリティの問題がまとめられているとして、バラガンスキ氏は次のように話す。「大半のセキュリティ担当者は、ここに掲載されている潜在的なリスクの少なくとも4分の3は考慮が及んでおらず、潜在的リスクの可能性の評価が各企業に委ねられていると考えられる」

　「自社の潜在的リスクの影響を評価できなければ、恐らく予算を誤った用途に使うことになるだろう」

　標準やフレームワークが何もない中で、最も重要なのは問題の認識だとバラガンスキ氏は指摘する。問題点を認識すれば、セキュリティは義務ではなく、開発者のアジリティーやビジネス継続性を向上させる便利なツールの一つだと考えられるようになる。

　「マイクロサービスは、一見アプリケーション開発の複雑さを緩和するように見える。開発者、運用担当者、業務担当者にとっては素晴らしいものだ。だが、さまざまな部分に複雑さが隠れていることを認識する必要がある」と同氏は言う。

　複雑さはなくならない。「Kubernetes」のような技術スタックやサードパーティーベンダーに複雑さが分散されるだけだ。それを理解して絶えず意識しなくてはならない。マイクロサービスアーキテクチャを使用することで、複雑さが増すレイヤーが追加され、誰かがそれらのレイヤーを管理しなければならない。

　「それらのレイヤーがさらされる新しいリスクについて、誰かが考えなければならない。部分的にはサードパーティーの責任になるとしても、セキュリティの脆弱（ぜいじゃく）性からデータを失った場合、結局苦しむのはコードとデータを所有する企業だ」