リソース

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

最近のセキュリティ事故のニュースを見ていると、同じ問いが繰り返し浮かぶ。「攻撃者がすでに内部に侵入していたら、私たちは何を防げるのだろうか」

2026年11月7日

[第2回] QueryPie ACP Community Editionをインストールする — 導入検討のための最初の実習環境

侵入後に何を制御できるのかを確かめるため、MacにQueryPie ACP Community Editionをインストールした。アクセス制御の検証に進む前の準備として、導入手順、遭遇した問題、確認できた範囲を記録する。

2026年11月7日

[第3回] QueryPie ACPに最初のDBを接続する — 開発者の接続方法はどう変わるか

第2回ではMacにQueryPie ACP Community Editionを導入してログインした。今回はDBを接続し、実際にデータを参照する。気になったのは開発者側の操作だ。管理者がDBを登録したら、開発者はどこでSQLを実行するのか。Webだけなのか、使い慣れたDBクライアントでも接続できるのか。

2026年11月7日

[第4回] QueryPie ACPの読み取り専用権限でUPDATEを実行したら — クエリ遮断、権限取り消し、監査ログまで

前回はQueryPieにDBを登録し、DBeaverで注文を参照した。接続情報の手入力とMulti Agentの両方を試した。参照できたので、今回は逆を試したい。読み取り専用の開発者がUPDATEしたり、管理者がアクセス権を取り消したりするとどうなるだろう。

2026年11月8日

[第5回] QueryPie ACPでDB権限を申請・承認する — DBeaverでの参照まで試した

「注文の精算明細を確認したいので、明日までDBの参照権限をもらえますか」。DB運用ではこうした依頼をよく受ける。対象DB、必要権限、利用期間を確認する仕事だ。人数が増えるほど、誰が何のために権限を得たかの管理が重要になる。

2026年11月8日

[第6回] QueryPie ACPでSQLを承認してデータを変更する — 通常の参照権限を維持し、必要な作業だけ実行

本番DBを参照していると、配送済みなのに状態が古いなど、1、2件を修正したい場面がある。簡単な変更でも本番データなら誰が何のために変えたかを残したい。第5回のアクセス承認に続き、今回はSQL承認を試した。

2026年11月8日

[第7回] DB参照は許可し、個人情報を隠す — QueryPieデータマスキング実習

第6回では参照権限を維持し、承認済みSQLで必要なデータだけを変更した。今回は参照結果に何が見えるかを考えた。配送状態の確認に顧客の電話番号やメール全体は必須ではないが、注文参照そのものを止めるわけにもいかない。

2026年11月8日

[第8回] 誰が顧客情報を参照したのか — QueryPie監査ログでDB利用履歴をたどる

第7回では電話・メールを開発者向けに隠し、原文が必要な担当者だけを例外にした。今回は配送問い合わせの後で「4002番を誰が参照したか」と聞かれたら、管理者はどこで何を確認できるかを試す。

2026年11月8日

[第9回] 注文参照は許可し、精算情報は保護する — QueryPieのテーブルアクセス制限

DB接続を許可しても全データを見る必要はない。注文を確認する開発者に精算金額や内部メモまで必要とは限らない。同じDBに両テーブルを置き、QueryPie ACPで注文参照を維持しながら精算を制限した。

2026年11月8日

[第10回] 「必要な列だけを参照してください」— QueryPie Query RulesでSQL利用ルールを適用する

「参照には必要な列だけを指定する」。DBを共有するチームなら決めたことがあるルールだ。状態だけ必要でもSELECT *では金額なども取得してしまう。今回はQueryPie Query Rulesでこの方針を適用した。

2026年11月8日

[第11回] 隠された電話番号が必要なとき — QueryPieのマスキング解除申請と承認

マスキングでは注文を見せたまま電話・メールを隠せた。しかし配送問い合わせ担当者は顧客へ連絡する必要もある。その都度管理者に全体設定の変更を頼むのか。今回はQueryPieの解除申請を試した。

2026年11月8日

[第12回] DB資料も承認を受けてエクスポートする — QueryPie SQL Export実習

参照結果を報告書へ移すことがある。配送状況の整理や金額比較はファイルが便利だが、誰が何を何の目的で取得したかも管理したい。今回はSQL Export Requestで注文概要を出力した。

2026年11月8日

[第13回] 精算情報が必要なとき — QueryPieの制限データアクセス承認

第9回では注文を許可し精算を制限した。普段は不要でも金額照合には必要になる。今回はRestricted Data Access Requestでポリシーを維持したまま、期間を定めて承認を受けた。

2026年11月8日

[第14回] 実行中のSQLを止める — QueryPieクエリモニタリング

権限や承認を整えても、実行中SQLを確認する場面はある。遅いとの連絡があれば誰がどのDBで何を実行したかを調べる。今回はRunning QueriesでWebエディターのテストSQLを見つけて止めた。

2026年11月8日

[第15回] チームに加わるとDB権限も付く — QueryPieグループ管理実習

最初は一人への権限付与で十分でも、チームが増えると個別確認は煩雑になる。注文分析グループに参照権限を設定し、個人へ直接付与せず新担当者を追加して試した。

2026年11月8日

[第16回] このDB権限は誰が付与したのか — QueryPie管理者の変更履歴

分析グループを作って利用者を追加した後、引き継ぐ担当者も今の権限の経緯を説明できるかが気になった。QueryPieの監査でグループ作成、権限付与、構成員追加を探した。

2026年11月8日

[第17回] このユーザーは何をしたのか — QueryPieユーザータイムライン

「DBには接続できるのに一つの操作ができない」。ログイン、接続、SQL制限を切り分けたい。今回はUser TimelineでDemo Analystの参照成功とUPDATE遮断を一つの流れで追った。

2026年11月8日

[第18回] 一時権限にも終了時刻が必要だった — QueryPieポリシー例外管理

「精算金額だけ少し確認したい」。権限を開いた後はいつまで許可するかも管理したい。業務が終わって例外だけ残る事態を避けるためだ。

2026年11月9日

[第19回] 注文変更後に元の値も確認する — QueryPie DML Snapshot

第6回では常時書き込み権限を与えず承認SQLを実行した。今回は誰が何を実行したかに加え、実データの変化も見たい。架空注文をPENDINGからDELIVEREDへ変えてDML Snapshotを確認した。

2026年11月9日

[第20回] 監査に必要な記録だけを抽出する — QueryPie Audit Log Export

第19回では注文の変更前後を確認した。今回は特定ユーザーのDB作業を監査や内部点検に渡すため、記録を出力した。期間と人で絞ると参照と承認UPDATEがまとまり、SQL、結果、申請UUIDまで含まれた。

2026年11月9日

[第21回] 監査担当に必要な権限だけを渡す — QueryPie管理者ロールの分離

前回は管理者で監査閲覧・出力を行った。実運用では設定者と点検者は別かもしれない。今回は変更記録、DML Snapshot、取得を行える監査ロールを作り、DB設定は開けないことを確認した。

2026年11月9日

[第22回] サーバーパスワードを入力せずSSH接続する — QueryPie Webターミナル

DBに続いてサーバーを試した。接続者へ都度パスワードを伝える代わりに、Ubuntuを登録してSSHロールを付与した。開発者はログインしてサーバーとアカウントを選び、パスワード入力なしでWebターミナルを開けた。

2026年11月9日

[第23回] サーバー接続を許可し削除コマンドを止める — QueryPieコマンド制御

パスワードを渡さないWeb接続に続き、ログイン後のコマンドを制限した。アカウントとファイルは確認できるがrmで消せない設定だ。テストファイルとCommand Templatesで試した。

2026年11月9日

[第24回] サーバー作業を再生して確認する — QueryPieセッション録画

前回はrmの入力者と遮断を監査で確認した。今回はSession Logsでターミナルを再生し、制限された瞬間とその後の確認を見た。Command Auditから該当時点へ直接開ける点が便利だった。

2026年11月9日

[第25回] MCP経由のDB参照でも権限は維持された — QueryPie Community MCP

AIツールとDBをつなぐとき、まず誰が何を見られるかが気になる。注文は参照し、精算は既存権限で保護したい。QueryPie CommunityへMCP Inspectorを接続して両方を試した。

2026年11月9日

[第26回] Kubernetes設定は読み、変更は止める — QueryPieのロールとアクセスポリシー

稼働中Kubernetesの確認に変更権限まで必要とは限らない。QueryPie CommunityでConfigMap参照を許可し変更は拒否した。両操作を同じ監査画面で確認した。

2026年11月9日

[第27回] DBeaverはそのまま、DB直接接続は閉じる — QueryPie接続経路の整理

権限と記録をQueryPieで管理しても、旧DBへの直接経路は別途整理が必要だ。DBeaverで直接・Proxyを比較して直結ポートを閉じ、新しいQueryPie接続と監査が使えることを確認した。

2026年11月9日

[第28回] 禁止した削除コマンドが必要なとき — 承認された時間だけ使う

第23回では接続を許可しても削除は禁止した。ただ、古いファイル整理などで必要な場合もある。通常制限を維持し、Server Privilege Requestでrmを5分だけ申請した。

2026年11月9日

[第29回] ログは確認し、コンテナのシェル接続は制限する

障害調査はログから始まるが、見る人全員にコンテナ内コマンド実行権限が必要とは限らない。第26回に続き、同じPodでログ参照とシェル接続をQueryPieで分けた。

2026年11月9日

[第30回] 接続中のサーバーセッションを見つけて終了する

ログイン後も誰が接続中か確認し、必要なら特定接続を終える管理が必要だ。第24回の終了作業再生に続き、今回は稼働SSHを終了し、同じロールで再接続できるか確かめた。

2026年11月9日

[第31回] サーバーファイルは取得し、アップロードは止める

本番の状態ファイル確認にアップロード権限まで必要とは限らない。QueryPieのWeb SFTPで転送後、アップロードだけを禁止し、取得を続けられるか確認した。

2026年11月9日

[第32回] 参照理由をSQLと一緒に残す

SQL監査は誰が何を実行したか分かるが、配送問い合わせか処理照合かまでは分かりにくい。QueryPieで実行理由を必須にし、異なる目的の2件を参照して監査を確認した。

2026年11月9日

[第33回] DB権限と接続履歴を一つの報告書にまとめる

点検では現在の権限と最近どのDBを使ったかを知りたい。QueryPie ReportsでDemo Developerの両資料をまとめ、概要と詳細ファイルを確認した。

2026年11月9日

[第34回] 同じサーバーのDBも業務別に権限を分ける

同じサーバーに複数業務のDBがあっても、注文担当に精算まで開く必要はない。テーブル制限に続き、今回は一つのMySQLで注文DBだけを許可する論理DB権限を試した。

2026年11月9日

[第35回] WHEREを忘れたUPDATEとDELETEを止める

1件変更のUPDATEでWHEREを忘れると全体に影響し、DELETEなら全行を消しかねない。変更・削除可能アカウントでQueryPieの保護を有効にし、条件あり・なしを比較した。

2026年11月9日

[第36回] 参照は許可しファイル出力は別に管理する

配送確認は画面参照だけで足りる場合もある。Web SQLで参照と出力を分け、3件をCSV取得した後、Can Exportだけを外して画面の差を確認した。

2026年11月9日

[第37回] SQL承認前に実行計画も確認する

SQL承認では本文と理由を見る。計画があればテーブルやインデックスも確認できる。SQL Requestに添付し、承認者も同じ資料を開けるか試した。

2026年11月9日

[第38回] サーバータグを変えるとグループ構成も変わった

登録・付与に続きサーバーの分類管理を試した。Server Groupsはタグ条件を使える。同じサーバーをタグと手動の両グループに入れ、タグ変更時の構成を比較した。

2026年11月9日

[第39回] DB担当者が変わっても承認規則はそのまま

DB担当変更のたび規則の人名も直す必要があるのか。Connection Ownerを使い、最初の申請を処理した後、接続担当だけを変えて次の配属先を確認した。

2026年11月9日

[第40回] DB権限を維持し、許可IPを定める

参照権限があっても指定ネットワークだけで使わせたい場合がある。Allowed Zoneで人と権限を維持したままIPだけ変更し、復元後に参照が戻るか試した。

2026年11月13日

[第41回] 参照用・作業用権限へ異なるDBアカウントを接続する

DBでは参照と作業のアカウントを分けることがある。その区別をAdvanced Privilegeへ接続し、権限で実アカウントが変わるか、両者が監査へどう残るかを試した。

2026年11月13日

[第42回] 運用DB作業に二段階承認を付ける

DB作業は一人の確認だけでは不十分な場合がある。開発がSQLを、運用が対象と目的を確認する二段階をSQL Requestに設け、注文1件のSELECTを実行した。

2026年11月13日

[第43回] 普段のMacターミナルからサーバーへ接続する

慣れたターミナルでアカウント・ファイル・コマンドを確認したい。MacからMulti Agent経由で接続し、通常操作と制限削除を試して接続・コマンド監査を確認した。

2026年11月13日

[第44回] kubectlを使い続けながらアクセス範囲を分ける

Kubernetes運用ではkubectlが日常の道具だ。確認ごとにWebへ移らず、Multi Agent経由でConfigMapの参照・変更を試し、役割ごとの処理を確認した。

2026年11月13日

[第45回] コンテナ内の作業も再生して確認する

コンテナに入った記録の次は、何をして何を見たか知りたい。テストPodで短く点検し、Pod Session Recordingsで接続と実画面をつなげて確認した。

2026年11月13日

[第46回] QueryPieでサーバーアカウントのパスワードを変更する

変更はボタンを押すだけでなく疎通と利用者の再接続も必要だ。台数が増えると更新把握も難しい。Password Provisioningでテストアカウントを変更し、接続と実行まで確認した。

2026年11月13日

[第47回] 遮断されたSQL実行を通知で受け取る

SQL遮断は確認済みだが監査を常時見ずに試行を知れるだろうか。Alertsで読み取り専用UPDATEの通知を受け、監査と照合した。

2026年11月13日

[第48回] 外部保守担当には必要な作業だけを任せる

外部保守のDB点検では範囲が重要だ。注文確認に変更権限は不要で、終了後もアクセスを残したくない。テスト担当者の参照申請から承認、点検、回収、確認まで行った。

2026年11月13日

[第49回] 注文を1件変更すると、どのような記録が残るのか

本番DBの値を変更したときは、変更したという報告だけでは経緯を説明しきれないことがある。今回は注文1件の訂正を通じて、変更理由、SQL承認、実行、変更前後の値、監査ファイルの出力までを確認した。

2026年11月13日

[第50回] 侵入後、攻撃者はどこまで進めるのか — ACP最初の連載を終えて

この連載は、アカウントが1つ漏えいしたあと、被害がどこまで広がるのかという疑問から始まった。DB、サーバー、Kubernetesを試した全50回を振り返り、実際に設定した制御と確認できた結果を整理する。

2026年11月13日