セキュリティ・キャンプ2025参加レポート

みなさん、お久しぶりです。
セキュリティ好きですか？好きですよね？？(圧)

というわけで、セキュリティ・キャンプ 2025 全国大会へ参加してきました！
ここでは、そこで学んできたことをいくつか話そうと思います。

とにかくセキュキャン愛が強い記事になっています。
画像がないのは講義資料をあまり写せないからです。勘弁してください()
そしてこれを読んでいるであろう中高大学生の皆さん、セキュリティ・キャンプへ行こう！！

こちらの記事もご覧ください。
https://note.com/yuito_it_/n/n035736d5b485

セキュリティ・キャンプってなんぞや

セキュリティ・キャンプとは、IPA とセキュリティ・キャンプ協議会が主催している、22 歳以下(ネクストは 25 歳以下、ジュニアは 15 歳以下)が対象のセキュリティについて学ぶイベントです。

応募課題

まず、応募課題なるものがありまして...
もちろんですが、選考があります。
あれだけの人数が全員受けられるとは限らないのです...(悲しい)

私は専門 B に応募しました。

難易度

やっぱり、難しいです。
OIDC や Passkey の話、Top 10 web hacking techniques of 2024 の話もありましたね。
必須と選択があるわけなので、私は OWASP の話は書いていません...

提出した応募課題(抜粋)

Q.5（1）

私は Proxmox VE でパスキー認証を利用しています。Proxmox は重要なサーバー管理ツールなので、高いセキュリティが求められます。パスキーは安全性が高い認証方式ですが、端末を紛失したり故障した場合、他の端末からログインできない問題があります。Proxmox には TOTP やリカバリーコードの代替手段がありますが、設定していなかったり、それらを失くしていることも多いです。このため、運用上のリスクが大きくなっています。

また、管理者から見ると、WebAuthn の設定画面は分かりにくく、パスキーや YubiKey との違いも分かりづらいです。この点は設定ミスやユーザーの混乱につながりやすいと感じます。

解決策としては、設定方法を分かりやすくするドキュメントや案内を増やし、代替認証の設定を促す仕組みを作ることが必要です。こうした対応で運用の負担を減らし、安全で使いやすい環境を作れると思います。

Q.5（2）

まず、認可とは、ある特定の権限を持っているかを確認・実証することで、認証とは誰であるかを確認・実証することです。例としては、社内 Wiki でシステムに ID とパスワードを入れてログインすることによって、そのユーザーが本人であることを確かめること、これが認証であり、認証されたユーザーがページを表示する権限を持っているかを検証することが認可です。

そして、OAuth 2.0 は、あくまで認可のプロトコルで、認証として使うには脆弱性が伴います。そして、OIDC では認可としてしか使えなかった OAuth に ID トークンを渡し、ハッシュ値の仕組みを使って置き換えられているかを確認することによって、置き換え攻撃を防いだりして認証にも使えるようにしたものです。WebAuthn は認可としては使うことができず、認証のみに使用できるブラウザ API です。そのため、認証のために OIDC を使用している場合は WebAuthn に置き換えることができると言えることまでわかりました。

Q.5（3）

従来の認証方式では、パスワードは誰かに覗き見られたり推測されたりするなどの脆弱性があったり、OTP に関してもマルウェアなどで Secret が流出してしまうことがあったり、フィッシングなどのリスクがあります。そして、SMS に関しては近年 SMS が使用できない SIM も出現し始めていたり、逐一携帯電話やメッセージアプリを開かなければならない煩わしさがありました。
一方 Passkey では、生体認証を使っているのでソーシャルエンジニアリングのリスクがなく、フィッシングなどの心配もない上、他のアプリケーションを開く必要がないためスピーディーに認証することができます。

他方で、従来の認証方式では、標準なスマートフォンがあれば全て使用できましたが、パスキーでは、まだ WebAuthn に対応していないブラウザーもあるため注意が必要です。また、別の端末にパスキーの設定を移行できない端末も多々あるというデメリットがあります。

Q.5（4）

FIDO2 の仕様に従い、サーバー側で登録するのに必要なチャレンジの生成ができるロジック、送信するロジック、登録時にブラウザから送信される AttestationObject を同じく送信される公開鍵で検証するロジック、ユーザー ID と公開鍵を DB に保存するロジック、ブラウザから送信される AssertionObject を DB から取得したユーザーの公開鍵で検証して結果を返すロジックが必要になることがわかりました。
また、従来の認証方式で認証したのちにパスキーを登録する仕組みも必要となることもわかりました。
しかし、AssertionObject や AttestationObject がサーバーのチャレンジやクライアントの情報を含んでいることまではわかりましたが、詳細はまだ理解できていません。

Q.5（5）

パスキーでは生体認証を使用するため、従来の認証方式よりもセキュリティを向上させることができること、パスキーが使用している WebAuthnAPI は特定のブラウザや端末では動作しないことを説明します。

監視

セキュリティ・キャンプの専門 B では、B1-6 までの講義があったわけですが、これは B1 の話ですね。

受ける前

受ける前までは、ログは適当に収集してはいたものの、なんとなくで収集していただけであまりちゃんとした分析はしていませんでした。
ログは集める方がいいっていうのは知ってたので、とりあえず集めていました。

ログを取るのが第一歩

ログを取ること、それがセキュリティの第一歩。
ログを取らなければ、インシデントにも対応できませんし、攻撃を受けている、またはその兆候を検知することもできないのです。

そして、外部に保存しておくことも大事です。
内部に保存しているだけだと、何かインシデントが起きた時に、吹っ飛ぶ可能性があります。
S3 や Datadog 等の外部に保存することが望ましいと学びました。

どのログに目をつけるか

次に、どのようなログに目をつけるかについても学びました。

デバッグであれば単にエラーログを漁ればいいだけかもしれません。
ですが、攻撃検知をするのであれば話は別です。

今回は、Google Workspace の監査ログを確認しました。

1. データを取り出すログ
2. ログイン試行/失敗のログ

まずはこのあたりから探索しました。

このログでは、

1. データを大量に取り出している

• もしかしたら乗っ取られたアカウントでデータを盗ろうとしているのかもしれない
• もしかしたら従業員がデータを抜き出して持ち出そうとしているのかもしれない

2. ログイン試行/失敗のログ

• もしかしたらブルートフォース攻撃かもしれない
• 普段と違う IP なら認証情報が盗まれているかもしれない

などということもわかるのです。

アラートを設定する

そして、当たり前ですが、我々がモニターに張り付いて常時そのログの検索のクエリを打つわけにはいかないのです。

少ない量のログであれば大丈夫でしょう。
しかし、大量になると流石に人の手で逐一検索するのは無理があります。

そこで、条件フィルターをつけて通知するということが大事です。
例えば、

• 閾値をつける
• IP アドレスが普段と同じかどうかを見極める

などがあります。
そして、その条件にマッチする怪しいログがあれば、即座に通知することが大切であるということも学びました。

しかし、例えば、業務時間内の大量ダウンロードがよくあるとすると、場合によっては通知がすごいことになってしまいます。
そこで、業務時間外と業務時間内で閾値を分けるということも必要になります。
このように、それぞれの制約条件や事情に応じて通知する条件を変更するということも学びました。

プロダクト設計とセキュアコーディング

脅威モデリング

まず、脅威モデリングについて学びました。
どこが脅威になり得るのか、などを考えます。

その際には、STRIDEというフレームワークを用いて考えることも学びました。

セキュアコーディング

私もそうでしたが、セキュリティは最後に検討するものと思っていました。
ですが、それでは、遅延を少なくするという理由でセキュリティが蔑ろにされるというのもよくありました。

Shift-Left

ウォーターフォールでセキュリティを考える工程を上流に組み込むことにより、セキュリティを担保しつつ作り直しによる遅延も少なくするというものです。

作り直すのが遅くなれば遅くなるほど、かかるコストは倍増します。
そのため、先にやっておくということがとても大事です。

DevSecOps

DevOps の中に組み込む方法です。
CI/CD パイプラインの中に trivy などを仕込んでチェックさせる方法も有効ということを学びました。

認証と認可/デジタルアイデンティティー

受ける前

OIDC/OAuth/FIDO についてはある程度は知っていましたが、語れるかと言われると微妙なところでした。

デジタルアイデンティティは大切

まず、デジタルアイデンティティは自己イメージのコントロール権、ひいてはプライバシーの権利にも深く関わっていることを学びました。
今までの自分にはなかった新しい視点でした。

FIDO と Passkey

Passkey の仕様について学びました。
また、古くからある FIDO の前の規格、U2F と UAF についても学びました。

OAuth/OIDC

OAuth は認可の基盤であるということを再認識しました。
また、OAuth で認証するとトークン置き換え攻撃などの脆弱性にさらされるということも分かりました。

それを防ぐために作られたのが OIDC で、これが認証のためのプロトコルであることも知りました。
また、それでも state などを適切に設定して、セキュリティ対策を講じなければならないとわかりました。

コンテナのセキュリティ

受ける前

何も対策してませんでした()

K8s ならではのセキュリティ

Kube API の隠蔽など、まずはコントロールを奪われないことが先決です。
また、Kube API の監査ログを監視してみるのも良いと知りました。

コンテナならではのセキュリティ

コンテナの分離性

コンテナは各コンテナが分離されているので脅威はないと考えていました。
ですが、コンテナブレイクやコンテナからコンテナへ通信が通る状況であることで、分離性が担保されず、脆弱になることもあると知りました。
対策として、ネットワークを制限することも重要です。

イメージ自体の脆弱性

イメージ自体が脆弱な可能性もあります。
trivyなどを使うと、イメージの脆弱性を検出できることもあります。

攻撃者の視点で考えてみる

[!NOTE]
この節は Confidential がいくらか含まれているので、あまり多くを語ることはできません...

ソーシャルエンジニアリングも多い

この講義を聞いていて、ソーシャルエンジニアリングが多いということに驚きました。
やはり、一番脆弱なのは人間なんだなぁ...と実感させられました。

セキュリティ・アーキテクチャについて考える

脅威モデリングとベストプラクティス

脅威を考える上で、脅威モデリングとベストプラクティスの適用の 2 つの方法があることがわかりました。

それぞれ、個別の事情を踏まえて検討できるが網羅性に欠ける、網羅性があるものの個別の事情に対応できない、という特徴がありました。

ドキュメントとして残しておく

考えたことをしっかりとドキュメントに残しておくだけで、なぜこのような仕様になったのか、と振り返る時間を節約できます。

脅威モデリングと脅威文法

今まで幾度となくやってきた脅威モデリングを最後にも行いました。
ただ、これまでと違うところは、脅威文法を用いて、対象と条件とどのような行動が脅威になりうるのかなどを特定したという点です。

また、脅威モデリングをしたとして、例えば認証情報が盗まれたら...という時に、どうやってという具体的な方法を導けないことが多くありました。
ですが、MITRE ATT&CKやOWASPを使うことにより、具体的に落とし込みやすいということも知りました。

対策

• 予防的コントロール
• 検知的コントロール
• 是正的コントロール
• 抑止的コントロール
• 復旧的コントロール
• 代替的コントロール

など、対策にもいくつか種類があることを知りました。

最後に

セキュリティ・キャンプではここに書いてあることだけでなく、とても多くのことを学ぶことができました。

中高生のエンジニアよ、セキュリティ・キャンプへ行け

また、B プロデューサーの藤田さん、並びに講師の皆様方、そして、とてもフレンドリーに話しかけてくださったチューターの皆様にここで感謝を表します。
5 日間ありがとうございました。

お読みいただきありがとうございました。