2026年2月に社内で行ったセキュリティ講義を記事化したものの、後編です。前編では「攻撃者の目」で自分たちのシステムを眺めるところから始めて、攻撃の99%を止める基本対策、そして偵察・OSINT・ソーシャルエンジニアリングといった「侵入の手前」で起きていることを扱いました。
後編は、その続きです。基本対策で止まらなかった残りの1%をどう考えるか。城壁で守る発想がなぜ通用しなくなったのか。そして、2026年のいま避けて通れないAIとセキュリティの関係について書きます。
では、残りの1%は？
前編で「基本対策で攻撃の99%は防げる」という話をしました。ここで必ず出てくるのが「じゃあ残りの1%は？」という質問です。答えを先に言うと、こういうものたちです。
- APT（Advanced Persistent Threat） — 特定の組織を狙って、長期間かけて静かに侵入し続ける攻撃。国家が背景にいることもある
- ゼロデイ攻撃 — 修正パッチがまだ存在しない脆弱性を突く攻撃。「更新しましょう」が効かない領域
- 内部犯行 — 正規の権限を持った人が加害者になるケース。認証を突破する必要すらない
- 想定外 — そもそも誰も想定していなかった経路。設計時に「ここは安全」と決めつけた場所
講義でも赤字で強調したのですが、ここではっきり言っておきたいことがあります。
100%の防御は存在しません。
これは諦めではありません。前提です。100%守れると思っているうちは、「破られたあと」の設計が一切できません。破られる前提に立って初めて、検知・封じ込め・復旧という発想が生まれます。
城壁モデルは、もう成り立たない
ひと昔前のセキュリティは、わかりやすい考え方をしていました。社内と社外の境界に高い壁を建てて、壁の内側は信頼する。ファイアウォールで囲って、その中は安全地帯。城と城壁のモデルです。
この前提はもう崩れています。理由は難しくありません。
- クラウド — データもアプリも、そもそも壁の外にある
- リモートワーク — 働く人が壁の外にいる
- SaaS・API連携 — 業務が外部サービスをまたいで成立している
- 持ち込み端末・私物スマホ — 壁の内側に、管理外の機器が入ってくる
守るべきものが壁の外に出て、守る対象の人も外にいて、外部サービスと常時つながっている。この状態で「壁の内側は信頼する」を続けると、一度でも内側に入られた瞬間、あとは全部やり放題になります。
攻撃者の目③ — 侵入したあと、彼らは何をしているか
ここが講義でいちばん反応が大きかったところです。多くの人は「侵入された＝即被害」だと思っていますが、実際の攻撃はそんなに急ぎません。侵入後は、だいたいこの順番で進みます。
- 侵入 — どこか1か所、弱いところから入る
- 潜伏・観察 — すぐには動かない。誰がどんな権限を持ち、どこに重要データがあるかを見る
- 権限昇格 — 一般ユーザーから管理者へ。より強い権限を手に入れる
- 横移動（ラテラルムーブメント） — 隣のサーバー、隣のアカウントへ静かに広がる
- 目的達成 — データを抜く、暗号化する、業務を止める
潜伏期間が数か月に及ぶことも珍しくありません。つまり、「今も気づいていないだけかもしれない」という可能性を、常に持っておく必要があるということです。
そしてこの流れを見ると、対策の打ち所も見えてきます。前編で扱った基本対策は主に①侵入の段階で効きます。でも②〜④の段階には別の考え方が要る。それがゼロトラストとサイバーレジリエンスです。
ゼロトラスト — 「信頼しない」ではなく「毎回確かめる」
ゼロトラストという言葉は、少し誤解されやすいと思っています。「誰も信用するな」という冷たい話ではなく、実務的にはこういうことです。
「どこから来たか」で信頼を決めるのをやめて、アクセスのたびに「誰が・何に・どの権限で」を確認する。
社内ネットワークから来たから信頼する、ではなく、社内からのアクセスでも都度確認する。エンジニアの実装レベルに落とすと、だいたい次のような話になります。
- 認証を「入口で一度だけ」ではなく、リクエストごとに検証する
- 権限は最小限で、必要な範囲・必要な期間だけ与える
- 内部通信も暗号化する（社内だから平文でいい、をやめる）
- 誰が何にアクセスしたかのログを、あとから追える形で残す
最後のログは地味ですが、ここが弱いと「侵入されたことはわかったが、どこまでやられたのかわからない」という最悪の状態になります。
サイバーレジリエンス — 折れないことではなく、戻れること
レジリエンスは「回復力」と訳されます。セキュリティの文脈では、攻撃を受けることを前提に、いかに早く元に戻れるかを設計しておくという考え方です。
問いの立て方が変わります。「どうすれば侵入されないか」だけでなく、こう問う。
- 侵入されたとき、どれくらいで気づけるか（検知）
- 気づいたとき、どこまでで止められるか（封じ込め）
- 止めたあと、どれくらいで業務に戻れるか（復旧）
バックアップを取っているのに復旧できなかった、という事例は本当に多いです。バックアップ先が本番と同じ認証情報でアクセスできる場所にあってランサムウェアに一緒に暗号化された、あるいは、リストア手順を誰も試したことがなかった。復旧は、試していないものは動かないと思ったほうがいいと思います。
作る人と、守る人
ここから少し、エンジニアとしての立ち位置の話をします。
セキュリティの世界では、しばしばBuilder（作る人）とDefender（守る人）が別の職種として語られます。でも実際のところ、作った人がいちばんそのシステムの弱点を知っています。どこを急ごしらえで済ませたか、どこにハードコードが残っているか、どのエラー処理を後回しにしたか。それを知っているのは設計者と実装者です。
だから私は、Builderが少しだけDefenderの目を持つのがいちばん効率がいいと思っています。専門家になる必要はなくて、実装しながら「これ、攻撃者から見たらどう見えるだろう」と一瞬だけ考える。それだけで塞がる穴がかなりあります。
攻撃者の目④ — あなたのシステムを、外から眺めてみる
講義では、参加者に自分の担当システムを思い浮かべてもらいました。ここで自問してほしいのは、次のような項目です。
- インターネットに直接見えているのはどこか。管理画面は外から到達できないか
- 認証が要らない、または弱い経路はどこか
- APIキーやトークンは、どこに置かれているか。リポジトリに入っていないか
- もっとも価値のあるデータはどこにあり、そこへは何段階でたどり着けるか
- 誰かがログインに100回失敗したとき、それに気づける仕組みがあるか
最後の項目が答えられないシステムは、けっこう多いはずです。攻撃者はそこを見ています。
作る側と守る側の、トレードオフの違い
もうひとつ、講義で強調した視点があります。BuilderとDefenderでは、天秤にかけているものが違うということです。
| Builder（作る側） | Defender（守る側） | |
|---|---|---|
| 評価される軸 | 速さ・機能・使いやすさ | 被害の小ささ・復旧の早さ |
| 成功の見え方 | リリースされる・使われる | 何も起きない（見えにくい） |
| 失敗のコスト | 作り直せばいい | 取り返しがつかないことがある |
| 時間の感覚 | 締切までに間に合わせる | 攻撃はいつ来るかわからない |
ここで大事なのは、どちらが正しいかではありません。成功が「何も起きないこと」である仕事は、評価されにくいという構造を、作る側が理解しておくことです。セキュリティ対応を「開発を遅らせるもの」と捉えるか「一緒に品質を担保するもの」と捉えるかで、組織の空気はかなり変わります。
AI時代のセキュリティ — 二つの方向
2026年のいま、この話を抜きにセキュリティは語れません。AIとセキュリティの関係は、大きく二つの方向に分けて考えるとすっきりします。
Security for AI — AIそのものを守る
AIを組み込んだシステムには、従来のアプリにはなかった攻撃面が生まれます。
- プロンプトインジェクション — 外部から読み込んだ文書やWebページに指示文を仕込まれ、AIがそれを命令として実行してしまう
- 学習データの汚染 — 学習・追加学習に使うデータに細工され、モデルの挙動が歪められる
- 機密情報の漏洩 — 社内データをAIに渡した結果、意図しない相手に出力されてしまう
- AIエージェントの権限 — 自律的に動くAIに強い権限を与えると、間違えたときの被害範囲がそのまま権限の広さになる
特に最後の項目は、AIエージェントが実務で使われるようになった2026年に入って一気に現実味を増しました。AIエージェントには最小権限を、というのは、もはや理屈ではなく実務要件です。
AI for Security — AIでセキュリティを強くする
もう一方の方向は、守る側がAIを使う話です。膨大なログの中から異常なパターンを見つける、脆弱性を含むコードを書いている途中で指摘する、インシデント発生時に関連する情報をかき集めて整理する。人間が全部見るのは無理な量を、AIが一次スクリーニングする使い方は着実に広がっています。
攻撃者の目⑤ — 攻撃者も、同じ恩恵を受けている
ここが、この講義でいちばん伝えたかったことのひとつです。
AIによる効率化の恩恵は、攻撃者にも平等に降り注いでいます。かつて「日本語が不自然だからフィッシングだとわかる」と言われていた時代は終わりました。標的の公開情報を集めて、その人向けの自然な文面を作り、大量に送る。この一連の作業のコストが劇的に下がっています。
つまり、攻撃の量が増え、質が上がり、狙われるハードルが下がった。「うちみたいな小さい組織は狙われない」という感覚は、前編で書いた空き巣の話と同じで、いよいよ通用しなくなっています。
知っておくと視野が広がる二つの言葉
SBOM（Software Bill of Materials） — ソフトウェアの部品表です。自分のプロダクトがどのライブラリのどのバージョンに依存しているかの一覧。新しい脆弱性が公表されたとき、「うちは影響を受けるのか」を即答できるかどうかは、この一覧があるかどうかで決まります。依存の依存まで含めると人間の記憶では追えません。
EDR（Endpoint Detection and Response） — 端末側で怪しい挙動を検知して、対応まで行う仕組みです。従来のアンチウイルスが「既知の悪いものを弾く」のに対して、EDRは「普段と違う動き」を捉えにいきます。前述の潜伏・横移動の段階を見つけるための道具、と理解するとつながりやすいと思います。
手を動かして学びたい人へ
セキュリティは、読むだけだとどうしても実感が湧きません。攻撃者の視点を安全に体験する方法として、CTF（Capture The Flag）があります。用意された演習環境の中で脆弱性を見つけて「フラグ」を奪う競技形式の学習です。
念のためもう一度書いておきますが、試すのは必ず、許可された演習環境の中だけで。前編の冒頭に書いたとおりです。
持ち帰ってほしい三つのこと
- 99%は基本で防げる。 多要素認証、更新、最小権限。地味ですが、ここが効きます
- 100%の防御は存在しない。 だから、破られたあとに気づける・戻れる設計を先に考える
- 攻撃者の目で、自分の作ったものを一度見る。 いちばん弱点を知っているのは、作った本人です
セキュリティ専門家になる必要はありません。ただ、実装しながら一瞬だけ「これ、外から見たらどう見えるだろう」と考える癖がつけば、それだけで防げるものが確実にあります。この記事がその癖のきっかけになれば嬉しいです。
付録：この記事に出てきた用語
- CIA三要素 — 機密性・完全性・可用性。セキュリティの目的を三つに整理した考え方
- OSINT — 公開情報からの情報収集。攻撃の偵察段階で使われる
- ソーシャルエンジニアリング — 技術ではなく人の心理を突く攻撃手法
- APT — 特定組織を狙い、長期間潜伏して続く高度な攻撃
- ゼロデイ — 修正パッチが存在しない段階の脆弱性を突く攻撃
- 権限昇格 — 侵入後、より強い権限を奪取すること
- 横移動（ラテラルムーブメント） — 侵入地点から他の端末・アカウントへ広がること
- ゼロトラスト — 場所で信頼を決めず、アクセスのたびに検証する考え方
- サイバーレジリエンス — 被害を受ける前提で、検知・封じ込め・復旧を設計すること
- 多要素認証（MFA） — パスワードに加え別の要素で本人確認する仕組み
- 最小権限の原則 — 必要な権限だけを、必要な期間だけ与える
- ランサムウェア — データを暗号化し、復旧と引き換えに金銭を要求する攻撃
- フィッシング — 偽サイト・偽メールで認証情報などを盗む手口
- SBOM — ソフトウェアの部品表。依存ライブラリの一覧
- EDR — 端末上の不審な挙動を検知し対応する仕組み
- プロンプトインジェクション — AIへの入力に指示を紛れ込ませ、意図しない動作をさせる攻撃
- CTF — 演習環境で脆弱性を見つけて競う、実践的な学習形式
前編とあわせて、社内講義の内容はここまでです。読んでくださってありがとうございました。2026年はAIとセキュリティの関係が大きく動いた年でもあるので、その話はまた年末あたりに、あらためて書ければと思っています。
