役に立つアクセス制御を決めるための質問

先に結果を定義する

アクセス制御は「誰が、どの記録に、どの条件で、何をしてよいか」という業務の問いから始まります。役割名の一覧だけでは不十分です。操作、所有範囲、例外権限を先に定めます。読む、直す、出力する、他人へ権限を与えることは別の力です。

適切な方法を選ぶ

小さな社内アプリなら単純な役割で足りる場合もあります。記録の所有者、所属組織、処理状態による追加確認が必要か考えます。少数の属性で明快に説明できるなら、組合せごとに役割を増やす必要はありません。OWASPは既定で拒否し、各リクエストで権限を確認する考え方を示しています。ボタン非表示は強制力のある境界ではありません。

具体例を照合する

架空の取引先ポータルで、営業担当は自社注文を読み、経理担当は請求書を取得するとします。他社ID、直接ダウンロードURL、検索結果で各操作を試します。ブラウザーを開いたまま所属を外し、次の保護されたリクエストで新しい権限が適用されることも確認します。以前の画面を信頼しないようにします。

使える証拠を残す

調査が楽だからという理由でサポートに常時無制限の権限を与えません。例外アクセスは理由、期間、記録を決めます。一括出力、バックグラウンド処理、連携用認証も画面と同じように確認します。権限表は、実行される検証と拒否テストにつながって初めて機能します。

操作と境界から権限表を作る

意味のある操作を行、役割を列にし、記録の範囲も書きます。担当組織の注文だけ読めるという条件は注記ではなく権限そのものです。検索、取得、一括出力、裏側の処理、他人への権限付与も含めます。編集だけ保護して出力を忘れれば、同じ情報が漏れることがあります。

招待、所属確認、役割変更、削除まで権限の生涯をたどります。二人目の確認が必要な変更と緊急権限の期限を決めます。業務を動かす権利とアプリを管理する権利を分け、購買承認者だからと認証設定や他社記録への権限を与えません。連携用IDも実際の仕事に絞り、所有者と失効手段を持たせます。

表を成功と拒否の例に変えます。許可された記録、同役割だが別組織、所属取消、画面を迂回した直接操作を試します。選択と実行の間に権限が変わる一括処理やキューも確認します。機微な操作の承認者を説明できる監査は残しつつ、個人情報の全文をコピーしません。その証拠で拒否を調べてもらいます。拒否は境界を守り、他人の記録を見せず正当な利用者に修正の道を示します。

権限の受入例

責任者への質問

誰が付与・取り消しを行うか。自分の昇格を承認できてしまわないか。同じ役割でも分ける記録は何か。役割・操作・記録の表と拒否すべき例を持ち寄り、許可と同じ重さで禁止も検討します。