[第28回] 禁止した削除コマンドが必要なとき — 承認された時間だけ使う
2026年11月9日
第23回では接続可能でも削除を禁止した。運用では古いファイルの整理など、通常制限したコマンドが必要になる場合もある。
制限を維持してrmを5分申請した。承認前は遮断、承認後は実行でき、期限後の新接続では再び制限された。
普段は削除を制限しておく
SSH Operations Lab、labops、開発者のOperations Lab Operatorを維持した。Lab - Block Deleteでrmを制限する既存構成だ。
別の試験ファイルを用意した。WebターミナルでrmするとRestrictedとなり、再確認でもファイルは残った。

制限案内にはRequest Server Privilegeもあり、必要作業を承認経由で許可する流れにつながっていた。これを試す。
サーバーとコマンドを選び5分を申請する
Workflow → Server Privilege RequestでOperations Lab Operator、SSH Operations Labのlabops一つ、Commandsのrmを指定した。
5分、Privilege Start Trigger Grantとし、付与時点から計測する。理由は試験ファイルの整理だ。

Demo Approverを指定し自己承認を無効にした。承認者で対象・コマンド・時間を確認してコメントした。

対象・コマンド・時間がまとまり、選択アカウントでrmを5分許可する内容だと分かりやすかった。
承認後に同じファイルを整理する
開発者の接続画面のView Server Privilegeにrm、Grant、減っていく残り時間が表示された。

新ターミナルで存在確認後に同じrmを実行した。制限は出ず、再確認はNo such file or directoryで削除を確認できた。

通常ポリシーの変更やrmの削除・再登録は不要だった。原本と次の確認用の2個目を残して終了した。
期限後は再び削除が制限される
残り00:00:00を確認して新規接続した。ログインとファイル一覧は正常だった。
2個目をrmすると再びRestrictedとなり、ファイルも残っていた。

手動回収は行っていない。新接続に通常制限が戻り、普段の接続権限を維持したまま追加コマンドだけ時間管理できた。
承認と実際の操作記録を確認する
Command Auditは承認前Restricted、後Not Restricted、期限後Restricted。同じ人・ロール・labops・サーバーで順に残った。

Workflow Logsには申請・承認が別々に残り、各担当と時刻、理由、コメントを確認できた。

通常制限を維持し、アカウント・コマンド・時間を絞って許可し実履歴も残す方法がよかった。例外業務でも権限の開きっぱなしを減らせそうだ。
QueryPie Community 11.6.7と別Ubuntuで、各段階とも新しいWeb接続を使った。削除対象は実習ファイルのコピーだ。
参考: Server Privilege Request · Server Privilegeの管理 · Command Audit
![[第27回] DBeaverはそのまま、DB直接接続は閉じる — QueryPie接続経路の整理](/assets/content/acp-lab-notes/database-connection-path/01.webp)
![[第29回] ログは確認し、コンテナのシェル接続は制限する](/assets/content/acp-lab-notes/pod-shell-access/01.webp)