[第1回] 侵入後、攻撃者はどこまでアクセスできるのか — ACPを自分で試してみたい理由

最近のセキュリティ事故のニュースを見ていると、同じ問いが繰り返し浮かぶ。

「攻撃者がすでに内部に侵入していたら、私たちは何を防げるのだろうか」

脆弱性を見つけて修正し、不審な接続を遮断することは今も重要だ。ただ、アカウントが一つ盗まれたり、サーバーが一台感染したりしたときに、被害がどこまで広がるかも考える必要がある。

一度の侵入が別のサーバーへのアクセスや大規模な情報流出につながる構成なら、最初の侵入を検知するだけでは十分ではないからだ。

この点で、アクセス制御の重要性はさらに高まっていると思う。その課題を自分で確かめるために、QueryPie ACP Community Editionを使ってみることにした。

侵入後の被害を抑えるには

2026年11月5日付のNews1の記事「AIハッキングの速度に追いつけない…『侵入後の制御が鍵』」は、この考えを具体化するきっかけになった。
News1の記事原文を読む

記事では、AIによって攻撃に必要な時間と費用が減り、防御側が速度競争だけで対応することは難しくなっていると説明している。特に目を引いたのは、侵入後に攻撃者が内部システム間を移動する経路を遮断し、アカウントやサービスの権限を業務に必要な範囲と期間に限定すべきだという提言だった。

攻撃を素早く見つける能力とともに、発見するまでに攻撃者ができることを減らしておく設計が必要だという意味に受け取った。

実際の事故に表れたアカウントと権限の問題

実際に、セキュリティ事故の届出も増えている。韓国の科学技術情報通信部と韓国インターネット振興院が発表した報告書によると、2025年の事故届出件数は 2,383件となり、2024年の1,887件に比べて 26.3%増加した。もちろん、届出件数が攻撃の総数を意味するわけではない。それでも、企業が直面するセキュリティ事故の負担が増していることを示す指標ではある。
関連報道： セキュリティ事故の届出統計に関する報道

ここ数年の事例を見ると、その負担が大きくなる過程をもう少し具体的に理解できる。

SK Telecomの事例 — 入手した認証情報で別のサーバーへ

2025年に公表されたSK Telecomの侵害事故の最終調査結果では、攻撃者が入手した認証情報を使って別のサーバーにアクセスした過程が明らかになった。政府発表によると、一部のサーバーには別のサーバーのアカウントIDとパスワードが平文で保存されており、攻撃者はその情報を使って音声通話認証管理サーバーなどにアクセスし、マルウェアを設置した。

最初の侵入後に内部で得た情報が、次のシステムへ移動する手段になったわけだ。調査では、ログが残っていない期間について、一部の情報流出の有無を確認できなかったという限界も指摘された。アクセス権限の管理と記録の保持が、事故の拡大防止だけでなく、被害範囲の確認にも重要であることを示している。
政府の最終調査発表： SK Telecom侵害事故に関する政府の最終調査発表

Snowflakeの顧客環境の事例 — 正規アカウントが情報流出の経路に

海外では2024年に、Snowflakeの顧客環境を狙ったデータ窃取があった。Mandiantは、調査した事故では情報窃取型マルウェアによって漏えいした顧客の認証情報が使われ、該当アカウントには多要素認証（MFA）が設定されていなかったと説明している。

攻撃者は顧客アカウントで接続した後、データベースを調べてデータを抽出した。この事例で大切なのは、Snowflakeプラットフォーム自体の脆弱性を突いた攻撃とは断定できない点だ。盗まれた正規アカウントが、データへのアクセス経路になった。
Mandiantの分析： Snowflake顧客環境の事故に関するMandiantの分析

二つの事故は環境も原因も異なる。ただ、共通して気になったのは、攻撃者が一つのアカウントやサーバーを手に入れた後、どの権限でどこまでアクセスできたのか、という問いだった。

接続後に何ができるかも管理する必要がある

ログインに成功したからといって、そのアカウントのすべての操作が安全とは限らない。正規の従業員アカウントも盗まれる可能性があり、通常の管理ツールも攻撃に使われることがある。業務用に許可したデータ参照が、大規模な流出の起点になる可能性もある。

だからこそ、アクセス制御は「接続を許可するか」から、もう一歩踏み込む必要があると思う。

アクセス制御で確認すべきなのは、誰が接続するのか、どのリソースにアクセスできるのか、どの操作をいつまで実行できるのかだ。個人別のアカウントと追加認証、業務に必要な最小権限、権限の有効期限、機密情報の保護、アクセス・操作履歴を組み合わせる必要がある。

この基準をシステムごとに管理すると、抜け漏れが生じやすい。DB権限は取り消してもサーバーアカウントが残っていたり、一時作業のために付与した権限が数か月後も有効だったりする。人が増え、システムが複雑になるほど、こうした例外を一貫して管理することは難しくなる。

私がACP、つまりアクセス制御プラットフォームを必要だと考える理由はここにある。権限の付与と取り消し、操作の制御、監査記録を、実際の運用の中で継続して適用できる必要があるからだ。

QueryPie ACPで確かめたいこと

今回試すのはQueryPie ACPだ。公式のCommunity Editionインストールガイドでは、データベース、サーバー、Kubernetes、MCPのアクセス制御が主要機能として紹介されている。製品ドキュメントには、DBアクセスの申請と承認、アクセス有効期限の設定、読み取り専用権限、機密情報のマスキングなども案内されている。

例えば、障害分析のために本番DBを確認する場面を考えてみる。この場合に必要なのは、特定の作業に必要な参照権限と利用期間を定めることだ。個人情報の原文が不要ならマスキングされた値で業務を行い、誰が何をしたのかを確認できる必要がある。

そのアカウントが盗まれても、使える権限の範囲と時間が限定されていれば、被害を抑えられる余地がある。ただし、読み取り専用でも機密データを過剰に参照できれば、流出リスクは残る。実際に見えるデータと実行できる操作を点検する必要がある。

AIエージェントにも必要な最小権限

AIエージェントが業務に加わると、この問題はさらに重要になる。人の代わりに情報を参照し、ツールを呼び出すエージェントに広範な権限を与えると、誤った指示や悪意ある入力の影響も大きくなり得る。

先ほどのNews1の記事も、AIエージェントに最小権限を与え、支払い・削除・外部送信といった重要な操作には人の承認を設ける方向を示している。私も、エージェントが使えるツールとデータ、実行できる操作を分けて管理すべきだと思う。QueryPieのMCPアクセス制御がこの要件をどこまで支援するかは、今後の実習で確認したい。

アクセス制御を実際の運用に適用するということ

ただし、ACPの効果は実際の構成と運用に左右される。

ユーザーが制御ポイントを通らずにDBやサーバーへ直接接続できれば、ポリシーを迂回する経路が残る。プラットフォーム側で権限を適切に設定しても、元のシステムのアカウントに過剰な権限があったり、サービスアカウントのパスワードが漏れていたりすれば、別のリスクが生じる。

そのため、アクセス制御はネットワークのアクセス制限、元のシステムの権限管理、認証情報の保護、パッチ適用、エンドポイントでの検知、バックアップと併せて設計する必要がある。監査ログも保存するだけで終わらせず、確認と対応につなげなければならない。先ほどの事故を特定の製品一つで防げたとは言いにくい理由だ。

こうした条件も含めて、実際に確かめてみたい。

Community Editionで自分で始めてみる

QueryPie ACP Community Editionは最大5人のアクティブユーザーに対応し、発行日から1年間有効なライセンスで利用できる。小さなテスト環境で管理者と一般ユーザーを分け、アクセス制御の違いを確かめるのに適していそうだ。

最初の実習ではテストDBを接続し、次の点を確認する予定だ。

1. 権限のないユーザーの接続は遮断されるか。

2. アクセスの申請と承認を経て、必要な権限だけを受け取れるか。

3. 読み取り専用ユーザーによる変更操作は制限されるか。

4. 機密情報のマスキングとアクセス有効期限は想定どおりに適用されるか。

5. 許可された操作と遮断された操作は、どのような記録として残るか。

まだ自分で検証した結果はない。これからこのノートに、インストールの過程、設定で困った点、制御が働いた場面、追加の対策が必要だった部分まで記録していこうと思う。

ACPを調べる出発点は明確だ。

一つのアカウントや一台のサーバーが侵害されたときに、その事故がすぐに組織全体の被害へ広がらないようにしなければならない。

その目標を実際の運用環境で実現するには、誰が、どこに、いつまでアクセスし、何ができるのかを制御できる必要がある。QueryPie ACP Community Editionを使って、その制御が実際にどう働くのか、一つずつ確かめていこうと思う。

製品機能の参考ドキュメント

• QueryPie ACP Community Editionインストールガイド

• DBアクセス申請のユーザーガイド

• データマスキングの管理者ガイド