セキュリティ・キャンプミニとは
上位存在であるセキュリティキャンプ全国大会により多くの学生にチャレンジしてもらえるように、2日間で比較的易しい？内容の情報セキュリティの実習を体験する取り組み。IPAが主催しています。
自分は25年度の広島会場に参加しました。
参加後の報告もこちらで見ることができます（専門講座の ２日目 のみ）。
一日目(公開講座)
( 25年 10月24日(金) )
この日は公開講座と呼ばれる類のもので、現地参加50名、オンライン参加200名のハイブリッド形式で開催された。
私は東京駅構内のカフェで視聴した。時間は13:00から17:40まで。
受付開始が12:30なのだが、東京駅なんかそう行かないので、Wifiのあるカフェの場所がなかなか見つけられずかなり焦った。
テーマはサイバー犯罪、現実的な防御策、生成AIとセキュリティ業務の自動化、そして証券口座乗っ取りの事例の紹介。
三部構成だったが、どれも 便利になった社会は、そのまま新しい攻撃面も増やしている ということを伝えていた。
学び
1. サイバー攻撃は、もう大企業だけの災害ではない
最初の講義で印象に残ったのは、ランサムウェアがもはや特定業界だけの問題ではない、という話だった。
特に狙われやすいのは、セキュリティ対策が手薄になりやすい中小企業だという。
背景には、セキュリティの弱い企業を踏み台にして、その先の取引先や委託元まで被害を広げるサプライチェーン攻撃の増加がある。
さらに、侵入経路として多いのが、テレワーク対応で導入されたVPN機器やルーターの脆弱性だという。
便利になればなるほど、守るべき場所も増えるから対策費用はかなり高くなりそう、と感じた。
2. 「守り切る」より、「突破されても崩れない」が重要
講義では、VPNやRDPはあくまで入口の門番でしかない、という点が強調されていた。
門番は必要だが、そこを突破された瞬間に全部終わる設計では厳しい。
だからこそ、中に入られた後まで見据えた対策が必要になる。
ネットワークを分ける、アクセス権を絞る、重要な情報に簡単に届かせない。つまり、入口防御だけでなく、内部設計そのものに防御を織り込むという発想だ。
これは「セキュリティ・バイ・デザイン」にもつながる話で、BCPだけでなくERPのような基幹システムにも、最初からセキュリティを組み込む必要があるという考え方が印象に残った。
3. ログがないことは、無事だった証拠にはならない
調査に必要なログが、機器の初期設定のままだと残らない場合がある。
そして当然ながら、ログが残っていないからといって、情報漏洩していないとは言えない。
セキュリティというと 防ぐ ことに意識が向きがちだが、実際には後から 追える 状態にしておく”ことも同じくらい重要だ。
攻撃を100%止めるのが難しいなら、少なくとも何が起きたのかを把握できるようにはしておかなければならないという意識は持つべきだと感じた。
4. 証券口座乗っ取りは、金を抜くだけでは終わらない
後半で特に印象に残ったのが、証券口座乗っ取りの話だった。
個人的には「口座からお金を盗む」タイプの不正を想像していたが、実際にはもっと厄介だった。
犯人はまず安い株を自分たちで買っておき、そのうえでインフォスティーラーや偽アプリを使って他人の証券口座を乗っ取る。
そして大量の口座から一斉に買い注文を入れて株価を吊り上げ、上がったところで自分たちの株を売り抜ける。
つまり、乗っ取られた口座は「資金を奪う対象」ではなく、相場操縦のための道具として使われるわけだ。
証券会社側も、メールアドレス登録や端末認証、FIDO認証などで対策を強化している。
ただ、それに対してリアルタイムフィッシングのように、ID・パスワードだけでなく、その瞬間に届く二段階認証コードまで盗む手口も出てきている。
ここまで来ると、「二段階認証を入れたから安心」とも言い切れない。
認証が進化すれば、突破する詐欺も進化しているらしい。もう、いたちごっこらしい。。。
5. 生成AIはセキュリティ業務を変える。
生成AIとAIエージェントによるセキュリティ業務自動化の講義も興味深かった。
CSIRTの業務はもともと手動中心で、そこからSOARによって定型処理の自動化が進んできた。
ただ、SOARは単純作業には強くても、柔軟な判断は苦手だった。
そこにAIエージェントによる 自律化 が入ってきている、という流れには納得感があった。
一方で、AIの限界もきちんと語られていた。
AIは普通に嘘をつくし、検索AIでもハルシネーションは起こる。フォレンジックのように正確さが求められる場面では、それはかなり危ない。
だからこそ、RAGのように正しい資料やデータを参照させながら回答させる仕組みが重要になる。
AIはイメージもできるみたいです
6. 開発の現場も、“AIに実装させる前提”に近づいている
Vibe Coding、Cloud Code、Vibe Kanban、Codex CLI、仕様駆動開発。
このあたりの話を聞いていると、開発の現場そのものが少しずつ変わってきているのがよく分かる。
人間が自然言語で指示し、AIがコードを書く。あるいは、人間は仕様書を整え、実装はAIに寄せていく。
これまで「書く人」が担っていた役割の一部が、設計する人へと移っている感じがある。
- 講義が終わり次第、すぐに新幹線に乗って広島を目指した。
二日目
8:40 受付開始
なのですが、
ここで会場を広島市立大学の本キャンパスと勘違いするという痛恨のミスを犯し、30分ほど遅刻してしまった。
事前の宣誓書には「最初に行われる倫理講座に出席しないと受講を認めない」と明記されていたため、すぐに本部に連絡しました。
運営の方々の粋な計らいにより、なんとか続行することができた。
この時の温かい対応には、深く感謝しています。
サイバーセキュリティと職業倫理
1日目に引き続き、倫理に関する講義を受けました。
特に印象的だったのは「カップルのSNSを勝手に覗く行為はプライバシー侵害になりそうで、実際にはならない」ということ。法律と感覚のズレを実感しました。
あと、「この講座で得た知識は悪用すれば犯罪になる」という言葉を聞いて、改めて気が引き締まりました。
TLSプロトコルの仕組みを学ぼう
TLS （Transport Layer Security） とは、インターネット通信を安全に保つための仕組みです。
WebサイトのHTTPS通信やLINE・Discord・Zoomなど、私たちが日常的に使うサービスのほぼすべてで使われています。
TLS通信は、次の 3つの安全性 を保証しています。
| 要素 | 意味 |
|---|---|
| 秘密性 | 第三者に通信内容を盗聴されない |
| 完全性 | 通信内容が改ざんされていない |
| 認証 | 通信相手が本物であることの確認 |
これらが欠けると、盗聴・改ざん・なりすましのリスクが一気に高まります。
暗号の種類と役割
TLSでは目的に応じて複数の暗号技術を組み合わせています。
- 共通鍵暗号（AES-GCM など） ― データの暗号化と改ざん防止
- 公開鍵暗号（ECDHE など） ― 共通鍵を安全にやり取りするための鍵交換
- デジタル署名（RSA-PSS など） ― 相手の本人確認と完全性の保証
暗号化方式には大きく2種類あります。
-
ブロック暗号
データを固定サイズのブロックに分けて暗号化。一部が漏れても他のデータは守られます（前方・後方秘匿性）。
かつて使われていたCBCモードは脆弱性が見つかり、TLS 1.3では廃止されています。 -
ストリーム暗号
データの長さに合わせて鍵を生成して暗号化。軽量で鍵の使い回しが発生しないため安全です。
TLS 1.3では、「暗号化」と「改ざん検知」を同時に行う AEAD（認証付き暗号） が必須となり、AES-GCMやChaCha20-Poly1305が採用されています。
実習(ハンズオン)では2人組で暗号の復号に取り組みました。大学の講義でやった内容だったのでちょうど良い復習に。
余談ですが、会場内のWi-Fiに繋がらなくてチューターに助けを求めたところ、自分のMacがUK配列キーボードだったせいで妙なことに……。
講義の最後には、関連書籍やネットワーク系の勉強会 JANOG の紹介もありました。JANOGは気になるので調べてみようと思います。
設計・開発・テストにおけるセキュリティの実践
開発スタイルの変化
| 時代 | スタイル | 特徴 |
|---|---|---|
| 2000年代 | ウォーターフォール型 | 計画通りに順番に開発。変更が難しい |
| 2020年代 | アジャイル型 | 小さく素早くリリース。柔軟に変更できる |
| 近未来 | AI自動生成 | 便利な反面、AIが脆弱なコードを生成するリスクも |
AIがコードを書く時代になっても、セキュリティの最終確認は人間が責任を持つ必要があります。
キーワード
-
Shift-Left（シフトレフト）
開発の終盤に欠陥が見つかると修正コストが跳ね上がります。設計・実装の早い段階からセキュリティを意識することで、コストとリリース時間を大幅に削減できます。 -
DevSecOps
開発（Dev）・セキュリティ（Sec）・運用（Ops）が協力し合いながら、テストを自動化しつつ安全なシステムを素早く作る取り組み。
ツールを導入するだけでなく、チーム全体の文化と考え方を変えることが本質です。 -
リスクベースアプローチ
100%完璧なセキュリティは存在しません。
「自社で最も守るべき情報は何か」を見極め、優先順位をつけて継続的に改善していく姿勢が大切です。
テストの基本ルール
情報漏洩を防ぐため、テストに 本物の顧客データを使うのは厳禁 です。データのマスキングや合成データの生成ツールを活用して、適切なテストデータを準備します。
また、エラーハンドリングのテストは手動と自動ツール（OWASP ZAP など）を組み合わせて行います。
ハンズオンでは、AIの力も借りてコードの脆弱性を調査しました。時間が足りず原因の特定まではできませんでしたが、ログの分析方法や狙われやすい脆弱性の箇所の特徴を実際に見られたのが面白かったです。
感想
唯一の首都圏からの参戦ということで、普段は関わることが少ない広島の学生の方々とお話をすることができ、とても刺激を受けました。
課外活動などで開発経験のある方が多く、自分がこれからどんなことを学べば、開発に応用が利くのかについて少し見えた（ような気がした）のがよい収穫でした。
二日間ありがとうございました！
応募課題の回答については、こちらから！