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

外部保守へDB点検を任せる際は範囲を考える。状態確認に変更権限は不要で、終了後も接続を残す理由はない。

テスト利用者を外部担当とし、参照申請、別担当の承認、1件確認、回収後の参照不可まで一連で試した。

1. DBと作業内容を先に記載する

既存実習DBとアカウントで41001の状態・金額を確認するだけの作業にした。実顧客資料は使わない。

DB Access Requestで対象一つとRead-Onlyを指定し、状態確認・変更なし・終了後回収を理由に記載した。

期限は当日とし、承認者が目的・範囲・期日をDB名と併せて見られる構成だった。

2. 承認すると参照権限が反映される

既存規則のDemo Approverが内容を確認し、注文点検用参照を承認するとコメントした。

Approvedとなり、申請者と承認者、処理時刻が残った。担当交代や後の経緯確認の出発点になる。

利用者にRead-Only・Select・当日23:59:59が反映された。管理者の再付与は不要だった。

3. 参照はでき、変更は止まる

ConnectでSQL Editorへ入り、41001のREADY・25,000ウォンを取得し依頼の点検を実施できた。

同注文のUPDATEは権限不足で止まり、元データでも状態・金額の不変を確認した。

「確認だけ」という指示を実権限にし、変更まで付けずに任せられる点がよかった。

4. 点検終了とともに回収する

今回の承認権限だけを管理者で回収し、他の既存権限は維持した。

利用者を更新すると対象DBが消え、既存SQL Editorの同SELECTもこの接続で実行権がないと出た。

期限を待たず点検直後に回収した。予定より早く終わった保守にも対応しやすそうだ。

5. 申請から回収まで記録が残る

Access Control Logsに13:41:48の付与と13:44:24の回収が並び、申請付与と管理者回収を区別できた。

Query Auditは参照成功とUPDATE遮断を示し、アカウント、テーブル、SQL、理由まで見られた。許可だけでなく何をしたかも追えた。

外部保守が、目的・範囲の申請、承認、許可参照、回収という流れになり、承認者とSQLも残った。

作業を認めながら範囲が明確なのがよかった。必要点検を進め、未許可変更を防ぎ、終了権限を整理する姿を一度の実習で確認できた。