
はじめに
こんにちは、Cloudbase の Cloud Security チームでエンジニアリングマネージャーをしている堤です。
よく Cloud Security チームとはどんなチームですか?と聞かれることが多いのですが、私のチームでは、パブリッククラウドにおける設定ミスの検出を行う CSPM を軸とした機能開発を行っています。今回の記事に登場する演習課題も、設定ミスに相当します。
参考: CSPMとは?クラウドの設定ミスを対策する主な機能・導入のポイントを解説
Cloudbase については、サービスサイトもご覧ください。
今回は、Cloudbase の入社時の基礎を作るオンボーディングの話をします。
入社1週目、私は"攻撃側"になった
入社して数日後、Hack & Defense と書かれたタイトルとともに、入社オンボーディング演習が始まりました。まさにセキュリティ企業に入社したのだなあと感じる出だしで、私はわくわくしていました。手を動かす演習をやることは事前に聞いていましたが、内容については当日まで知らされていません。
第一の演習では、URL がひとつ渡されました。お題は一言、「目的は、ここから運転免許証(偽物)の画像を取得することです」。
開いてみると、いたって普通の Welcome ページが表示されました。これのどこから手をつければいいのだろうかと、しばらくページを眺めて、ページ内の怪しい箇所を探したり、ソースを開いてみたり、いくつかの試行錯誤を試みます。なかなか手がかりはつかめません。
ふと、URL を編集してルートパスを開いてみることにしました。すると、見慣れた Welcome ページのかわりに XML が返ってきます。よく目を凝らすと、そこには drivers-license.png という、いかにも怪しい文字列が並んでいました。パスを編集してそのファイルにアクセスすると、なんと運転免許証(偽物)の画像が、画面に表示されてしまいました。
普段なかなか実践することのない、自分が書いたコードや動かしているサービスに対して "攻撃する" という行為に、目の前で起きたことに少しドキドキしていました。
念のため少し解説します。S3 バケット全体をパブリックに公開すると、同じバケットに置かれた想定外のオブジェクトまで一緒に外から見えるようになります。とくに s3:ListBucket 権限がパブリックに付与されていると、バケットのルートを開いただけでオブジェクトの一覧が表示されてしまうため、攻撃者からは中身が極めて探索しやすい状態になります。今ではバケットはデフォルトでプライベートですが、過去にはデフォルトでパブリックに公開される仕様だった時代もあり、運用の経緯によっては古いバケットに同様のリスクが残っていることもあります。
このあと、二つ目の演習が出題されました。詳細は伏せますが、脆弱な検索ページが題材で、IMDSv1 の脆弱性を突くと、最終的に AWS の認証情報を取得できてしまう、というものです。これもなんとか回答にたどり着き、動いているクラウド環境から、取れるべきでないデータを取る瞬間を、もう一度味わいました。
"防御"に回って、ようやく分かったこと
演習はここで終わりではありません。 Hack & Defense のうちの Defense にあたる防御フェーズに移ります。
防御フェーズでは、Cloudbase 自身を教材として使います。Cloudbase の CSPM 機能で、先ほど自分が攻撃した環境をスキャンすると、まさに自分が突いた脆弱性が、検知結果として並んでいました。攻撃者の視点で見えていた "穴" が、こちら側からは "検知されたリスク" として現れます。
検知が出ているということは、設定を直せば消えるはずです。S3 バケットの ListBucket 権限をパブリックから剥がし、IMDS は v2 を強制する設定に変更します。直してから、CSPM をもう一度スキャンすると、検知結果は消えていました。もちろん、先ほどまでアクセスできていたデータにアクセスできないことも確認できました。
ここまでやって、ようやく演習の本当の構造が見えてきます。Hack だけだと、攻撃者の気持ちになるだけで終わってしまいます。Defense だけだと、機械的に「これは危ないですよ」と知らされる側で終わってしまいます。両方を、しかも同じ環境で順に経験することで、検知の意味が立体的に分かってくるのです。「ListBucket がパブリックです」というアラートを見たときに、自分の頭の中で、URL を編集してルートパスにアクセスし、XML からファイル名を拾い、そのファイルにアクセスする攻撃者の手順が、一気に再生されます。これがあるかないかで、同じ "検知" の重みは全く違ってきます。
この演習で、セキュリティリスクの重みや構造、そして Cloudbase プロダクトへの理解が深まるようになっているのです。
実はこれ、全社員がやっています
こちらの演習、エンジニアだけがやっていると思いきや、 Cloudbase では、なんと入社した全員がやります。ドメイン理解を深める観点で、全社オンボーディングの一部として組み込まれているのです。
クラウドセキュリティというドメインは、「クラウド」という専門領域と、「セキュリティ」という専門領域の二つが重なる、それなりに難易度の高いドメインです。クラウドだけ詳しくても、その上に乗っているセキュリティの考え方が分からないと、何が危なくて何が安全なのか判断できません。逆にセキュリティだけ詳しくても、クラウドの責任共有モデルや IAM の感覚を持っていないと、どこから手を付ければいいのかが見えてきません。
Cloudbase では、「入社してもらうまでが採用ではなく、入社した後にご活躍頂くことに組織としてオーナーシップを持つ」という考え方を大事にしています。私が入社した 2024 年時点では、まだ全社の人数は 30 名にも満たない規模でしたが、その規模感の中でも、ドメインも会社事情も働き方も含めたしっかりとした全社オンボーディングが組まれていました。Hack & Defense はその中の、ドメイン理解パートに位置付けられています。
なぜソフトウェアエンジニア以外もやるのか。理由は、クラウドセキュリティのドメイン理解が、職種を問わず Cloudbase のすべての仕事の前提になっているからです。プロダクトを作る人がドメインを分かっていないと、お客様の本質的な課題を解決できません。プロダクトを売る人がドメインを分かっていないと、セキュリティに向き合うお客様からは見向きもされません。サポートも、マーケティングも、人事も、あらゆる職種でドメイン理解が重要になってきます。
座学での網羅的なドメイン理解ももちろん重要です。実際、演習の前には、「セキュリティとは」「システムとは」「パブリッククラウドとは」「パブリッククラウドのセキュリティ」と段階的に解説する座学パートも用意されています。ただ、座学一回だけではなかなか頭の中に残りません。セキュリティの "危なさ" は、文字で読んだときよりも、自分の手で再現したときの方が、はるかに早く伝わります。
この「難易度の高いドメインの共通理解」が Cloudbase の早い意思決定やプロダクトデリバリーを支えているのです。
当時は演習を受ける側だった私ですが、約半年後に引き継いで講師側となりました。そこからさらに時間が経ち、今はさらに別のメンバーが引き継いでこの演習オンボーディングを続けてくれています。
社外でも同じ体験を届けています
この社内オンボーディング演習が源流になって、いまでは社外向けの勉強会としても展開されています。サポーターズ CoLab で「攻撃して学ぶ!」シリーズとして、ランチタイムのオンライン枠で開催している取り組みです。
シリーズが始まったのは 2025 年 4 月で、最初は VPoE の成瀬が AWS 基礎編を担当しました。基礎編から始まり、中級編、上級編とコンテンツが拡張され、2026 年 2 月からは Azure 基礎編も追加されています。AWS 基礎編は、いまは私が引き継いで登壇しています。
【勉強会】攻撃して学ぶ!全エンジニアが知っておきたいAWSセキュリティ(基礎編)
【勉強会】攻撃して学ぶ!全エンジニアが知っておきたいAzureセキュリティ(基礎編)
毎回 100 〜 200 人程度集まる人気コンテンツとなっており嬉しい限りです。クラウドセキュリティスキルを高めたいという方々のご参加をお待ちしております。プロダクト開発をしていく上で、セキュリティの知識は「知らないと対策できない」ため、全エンジニアの方にお勧めできます。
開催情報は https://x.com/cloudbase_inc でも発信されるので、気になる方はぜひフォローいただけると嬉しいです。
おわりに
「全社員が入社時にハッカーになる会社、Cloudbase」というタイトルで、ここまで書いてきました。少し大げさに聞こえるかもしれませんが、 Cloudbase がいかに本気でドメインに向き合うかが垣間見えたかと思います。
クラウドセキュリティを、知るのではなく、体で分かっている仲間が、職種を問わず周りにいる組織。それが今の Cloudbase です。
なお、エンジニア向けには、全社オンボーディングに加えてさらに開発に踏み込んだエンジニアオンボーディングが乗ってきます。
Platform Teamマネージャーが語る | エンジニアの力を最大限に引き出す組織づくりとは
興味のある方はそちらもご覧いただければと思います。
Cloudbase では、セキュリティプロダクトの開発を一緒に推進してくれるエンジニアを募集しています。 もしご興味がありましたら、ぜひお気軽にお問い合わせください。