[連載]ワークロード。死ぬほどむずい。人の認証だけではクラウドは守れない。人は間違いを犯す機械である。[第4回]

恐縮です。
さて後半戦です。

ここから先は私も導入経験が少ないものが多くなってきます。
まだ、トレンドが来ていないという感じで受け取ってもらえるといいかなと思います。とはいえ、今回のワークロード、次回のデータガバナンスは少しづつ導入検討されるお客様が増えてきてるので今後この波が来そうだなぁって思って日々勉強中です。
逆に言うとSASEまでは割と導入がすすんでるんだなぁと思っていただくのがいいのかもしれません。あくまでトレンドです。遅いとか早いとかではありません。

前回はこちら。

ゼロトラストの話は、どうしても人のアクセス制御に寄りやすいです。
IdPを整える。EDRを入れる。SSE/SASEで到達経路を引き直す。
ここまではかなり分かりやすい。

でも、ここで安心すると危ないです。
なぜか。
人の認証を固めても、アプリやクラウドの実行環境が甘ければ、そこがそのまま穴になるからです。

公開ストレージが残る。
過剰権限のロールが残る。
古いコンテナイメージが残る。
シークレットが雑に置かれる。
サービス間通信が広すぎる。
このへんが残っていると、ユーザーの入口をきれいにしても、裏側はかなり危ないままです。

だから先に言い切ります。
ワークロードの柱は、人ではなく、アプリと実行環境そのものを見る柱です。
ここを外すと、ゼロトラストはかなり片手落ちになります。

ゼロトラストの対象は、人だけではありません。
クラウド上のVM、コンテナ、Kubernetes、PaaS、サーバーレス、API、サービスアカウント、ストレージ、CI/CDまで含めて、何がどう動き、どこが危ないのかを見ていく必要があります。
ここまで見えて、はじめて「守れている」と言いやすくなります。

参考URL

ワークロードの柱は、人ではなくアプリと実行環境を見る柱

ここはかなり大事です。
ワークロードという言葉は、現場だと少し広すぎて、ふわっとしやすい。
でも、やることはかなり具体的です。

何のアプリが動いているのか。
どのクラウド資産が公開されているのか。
どのロールやサービスアカウントが強すぎるのか。
どのイメージが脆弱なのか。
どのシークレットが危ないのか。
どの通信が不要に広いのか。
ここを見て、減らして、閉じていく。
これがワークロードの柱です。

つまり、ここで見ているのは「人がどう入るか」ではありません。
アプリと実行環境が、どう動き、どう露出し、どう悪用されうるかです。
この視点がないと、ゼロトラストはどうしても“人の認証をきれいにした話”で止まりやすい。
それでは足りません。

特にクラウドでは、攻撃者は人のログインだけを狙うわけではありません。
公開された管理ポート、過剰権限のロール、雑に置かれたアクセスキー、古いイメージ、CI/CDの設定ミス。こういうところも普通に突いてきます。
だからワークロードの柱は、かなり重要です。

参考URL

なぜ人の認証だけではクラウドは守れないのか

ここはかなり誤解されやすいです。
IdPが整った。MFAも入った。SASEも入れた。だからかなり守れている。
この感覚は半分正しい。
でも、半分危ないです。

たとえば、社員のログインが完璧でも、S3やBlobが公開されていたら終わりです。
ユーザー認証がきれいでも、サービスアカウントが過剰権限なら横展開されます。
社内からの到達制御ができていても、CI/CDパイプラインに雑なシークレットが残っていれば、そこから崩れます。
つまり、人の入口を固めても、クラウドの裏側が開いていれば守り切れない。
これが現実です。

ここがワークロードの柱の怖いところです。
見えていないと、かなり長く放置されます。
しかも、問題が起きたときには「人の認証はちゃんとしていたのに、なぜ」となりやすい。
でも実際は、見ている対象が足りなかっただけです。

ゼロトラストは、信用を雑に置かない設計です。
だとすれば、人だけでなく、アプリ、実行環境、サービス間通信、マシンID、ストレージも同じように疑って見ないといけない。
ここを外すと、かなり苦しいです。

参考URL

CSPM、CWPP、CNAPPはどう分けて見るか

ここもかなり混ざります。
ワークロードの話になると、CSPM、CWPP、CNAPPが一気に出てくる。
言葉も似ている。機能も重なる。だから現場ではすぐ一塊になります。
でも、役割は分けて見た方がかなり分かりやすいです。

CSPMは、クラウド設定を見る側。
公開ストレージ、危ないセキュリティグループ、監査ログ未設定、暗号化不足、過剰権限など、クラウド設定のズレや露出を見つける。
いわば、設定の甘さを見える化する役目です。

CWPPは、実行中のワークロードを守る側。
VM、コンテナ、ホスト、ランタイムで何が起きているかを見る。
脆弱性、異常な挙動、不審なプロセス、イメージの問題、実行時の危険なふるまい。
つまり、動いているものの現実を見る役目です。

CNAPPは、その二つをまとめて、開発からクラウド本番まで一気通貫で見る側です。
IaC、イメージ、設定、権限、ランタイム、データ露出まで、バラバラだった視点をまとめて見やすくする。
だから最近は、CNAPPという見方がかなり主流になっています。

雑に言うなら、
CSPMは設定を見る。
CWPPは実行中の現実を見る。
CNAPPはその全体をつなぐ。
です。

ここを分けて考えると、どこから手を付けるべきかがかなり見えやすくなります。
設定ミスが多いならCSPMが効く。
コンテナやホストの実行リスクが痛いならCWPPが効く。
開発から本番まで断絶しているならCNAPPでまとめた方が強い。
つまり、ワークロードの柱も一つの箱ではなく、何を先に見えるようにするかの選択なんです。

参考URL

現場で最低限そろえたいもの

ワークロード編で最初に揃えたいのは、派手なダッシュボードではありません。
まず土台です。
ここを飛ばすと、かなりの確率であとで詰まります。

一つ目は、クラウド資産の棚卸しです。
何が動いているのか。
どのサブスクリプション、どのアカウント、どのプロジェクトに、どのVM、どのコンテナ、どのストレージ、どのPaaSがあるのか。
これが見えていないと、守る以前に対象が分かりません。
ここが一番危ないです。

二つ目は、公開面の棚卸しです。
インターネット公開されているものは何か。
管理ポートは開いていないか。
ロードバランサ配下は何か。
APIはどこに出ているか。
ここが見えていないと、攻撃面を減らせません。
見えない公開面は、かなり危ないです。

三つ目は、権限とマシンIDの整理です。
人の権限だけではありません。
サービスアカウント、ロール、アクセスキー、シークレット、トークン。ここが広すぎると、侵害後の横展開が一気に楽になります。
人よりむしろ、こちらの方が雑に残りやすい。
ここはかなり要注意です。

四つ目は、IaCとCI/CDの可視化です。
クラウドの問題は、本番だけにあるとは限りません。
Terraform、CloudFormation、GitHub Actions、GitLab CI、イメージビルド、リリースパイプライン。ここにミスや秘密情報があると、本番だけ直してもすぐ戻ります。
ここを見ないと、かなりつらいです。

五つ目は、ランタイムの監視とログです。
設定だけ見て終わると足りません。
本番で何が動いたか。どの通信が起きたか。想定外のプロセスはないか。監査ログは取れているか。ここまで見て、ようやく実態に近づきます。

六つ目は、例外を先に洗い出すことです。
古いコンテナ、止められない業務アプリ、所有者不明のクラウド資産、棚卸し外の検証環境、シャドーなサブスクリプション。
詰まるのはいつも例外側です。
標準環境だけ見ていると、かなり危ないです。

代表的な製品はこの3つから見れば外しにくい

ワークロードの柱で代表例を3つ挙げるなら、まずは
Wiz
Prisma Cloud
Microsoft Defender for Cloud
でよいと思います。

ここでも言いたいのは、どれが絶対に一番かではありません。
現場で比較対象に上がりやすく、考え方の違いを見やすい3つ、という意味です。

Wizは、クラウド資産、権限、露出、脆弱性、データ露出のつながりを見やすく、まず全体像を早く掴みたい現場でかなり比較しやすいです。
「何がどこで危ないか」を俯瞰したいときに見やすい。

Prisma Cloudは、クラウド設定からランタイムまで広く見たいときに比較しやすいです。
ネットワークや既存セキュリティ運用とのつながりも意識したい組織では、かなり自然な候補です。

Microsoft Defender for Cloudは、Azureを軸にMicrosoft系の運用基盤とつなげたいときに見やすいです。
Entra、Defender、Sentinelと流れを作りたい環境では、かなり候補に上がりやすいです。

大事なのは、製品が賢そうに見えるかどうかではありません。
自社のクラウド資産、権限、開発フロー、例外環境まで含めて、本当に見渡せるか。
ここで見ると、製品の見え方はかなり変わります。

※WizはGoogleに最近買収されました。今後、Geminiとかと連携してくる可能性が高いですが、GCP特有の部分に手を付けてくるかもしれませんね。
とはいえ、GCPなんて、シェアがねぇ。。。

参考URL

現場でよくある失敗は、だいたい同じ

一番多いのは、CSPMを入れて終わった気になることです。
設定ミスは見えるようになった。重大アラートも出る。画面もきれい。
ここまでは進んだ感じがする。
でも、誰が直すのかが曖昧。例外が多い。運用部門が動かない。開発チームが見ていない。これでは柱になりません。

次に多いのが、重大アラートが多すぎて誰も見なくなることです。
最初は盛り上がります。
でも、件数が多い、優先度が分からない、似た警告が多い、所有者が不明。そうなると、ダッシュボードだけ立派で、現場は何も変わらない。
ここはかなり起きます。

さらに多いのが、人のIDだけ見て、マシンIDやシークレットを放置することです。
社員アカウントは厳しくした。
でも、サービスアカウントは古いまま、シークレットはリポジトリに残る、アクセスキーは長寿命。この形はかなり危ないです。
人より静かに残るので、気づきにくいのが厄介です。

もう一つは、開発・インフラ・セキュリティが分断したまま進めることです。
ワークロードの柱は、どこか一部署だけでは回りません。
開発はコードを触る。
インフラは環境を作る。
セキュリティは見て止めたい。
ここが分断したままだと、問題は見つかっても直りません。
この形はかなり苦しいです。

最後に、所有者不明の資産が残り続けることです。
誰の環境か分からない。
止めていいか分からない。
検証環境が消えない。
古いクラウドアカウントが残る。
ここが残ると、どれだけ製品を入れても裏側が荒れます。
見えない資産、所有者不明資産、見直されない例外。ここはかなり危ないです。

この柱が整うと、次のデータの柱が回り始める

ワークロードの柱が整うと、次はデータの柱がかなり現実的になります。
ここから先は「何を守るか」をもっと具体的に詰める段階です。

なぜか。
ワークロードの柱が弱いと、どのデータがどこにあり、どのアプリが触り、どの経路で出ていくのかが曖昧です。
この状態では、DLPも分類も、かなり空振りしやすい。
守りたいのに、動きが見えていないからです。

逆に、ワークロードの柱が整うと、
どのストレージに何がありそうか。
どのサービスがどのデータに触るのか。
どこが公開面なのか。
どの権限が危ないのか。
ここがかなり見えやすくなります。

つまり、ワークロードの柱は単なるクラウド設定の話ではありません。
次のデータ保護の前提を整える話でもあります。
ここが見えると、ワークロードを先にやる意味がかなり腹落ちしやすくなります。

まとめ

ワークロードの柱は、人の認証をきれいにしただけでは守れない領域を埋める柱です。
アプリと実行環境そのものを見る柱です。
ここを大きく外すと、ゼロトラストはかなり片手落ちになります。

CSPMは設定を見る。
CWPPは実行中の現実を見る。
CNAPPはその全体をつなぐ。
この役割の違いを押さえながら、クラウド資産、公開面、権限、IaC、ランタイム、例外管理をつないでいく。
すると、ワークロードの柱はかなり強くなります。

最初に全部完璧である必要はありません。
でも、棚卸し、公開面、権限、パイプライン、ログ、このあたりを曖昧にしたまま進めると、だいたいあとで詰まります。
ここはかなりの確率で詰まります。
だから先に手を打つ。これが大事です。

人の認証が整っていても、クラウドの裏側が雑なら守れない。
この現実を直視するところから、ワークロードの柱は始まる。
そう思います。

恐縮でした。

次回はこちら