INSIGHT
ログインできた。それだけで、他の人の情報も守れたことにするな
ログインできたこと以外に、他の人の情報を見たり変えたりできないと確かめたか。
AIで作った試作品に、メールアドレスとパスワードで入れるようになった。自分の案件を開き、内容も更新できる。これなら他の人にも使ってもらえそうだ。ただし、自分が入れたことから、別の人には何が見え、何が見えないかは分かりません。
ログインが確かめるのは、入口にいる人です。その人が見てよい顧客、変更してよい情報、使ってよい機能は、入口を通った後に別途決めます。
本人だと確認できたことは、他の顧客の情報を読めず、変えられないことの証明ではありません。
認証は「誰か」、認可は「何をしてよいか」
認証は、利用しようとしている人が誰かを確かめる仕組みです。認可は、その人に、特定の情報や操作を許すかを決める仕組みです。
たとえば、顧客Aの担当者が正しいパスワードで入れたとしても、顧客Bの請求書を読んでよい理由にはなりません。同じ会社の中でも、一般担当者、管理者、経理担当者では、閲覧、更新、出力、削除の必要範囲が違います。「ログイン済み」「社員」「管理者」という一語では、顧客と操作の境界を表せません。
OWASPのAuthorization Cheat Sheet は、必要最小限の権限、既定では拒否する考え方、要求ごとの認可確認を扱っています。個別アプリの安全を保証する資料ではありませんが、ログイン後の各操作を試す観点になります。
画面からボタンを消しても、要求は残る
権限表には、一覧、詳細、検索、添付、ダウンロード、通知、連携機能、管理画面を並べます。各行について、誰が、どの顧客の、何を、読む・変える・出力する・削除するのかを書きます。
ここで大切なのは、画面に見える操作だけで終えないことです。ボタンを隠しても、別の顧客の案件番号をURLへ入れたら開けるかもしれません。以前保存したリンク、検索条件、連携先からの要求、添付ファイルのURL、出力済みファイルにも境界があります。
「見せない画面」を作ることと、「許されない要求を拒む」ことを分けて確認します。
権限表は技術担当だけの仕様書ではありません。業務責任者は、誰にその情報が必要かを決める。顧客対応担当は、訂正や削除の依頼を誰が受けるかを決める。運用担当は、異動や退職でいつ権限を外すかを決める。同じ表を使うことで、実装と業務上の約束を照合できます。
二社・二役・二方向で試す
顧客ごとに分けるアプリなら、試験用の顧客組織を二つ用意し、それぞれに一般利用者と管理者を置きます。社内用なら、部署や担当案件など実際に分ける境界へ置き換えます。管理担当の許可を得た環境・アカウント・データで、次の二方向を確かめます。他人の本番アカウントや実情報を、無断で試験に使いません。
- 許す側：自社の案件を読み、許可された項目だけを更新できる。
- 拒む側：他社の識別子を指定しても、一覧、詳細、添付、出力、更新へ進めない。
さらに、権限を変更した直後、利用者を停止した直後、古い画面を開いたまま操作した場合も試します。拒否されたことを画面だけで判断せず、対象、利用者、時刻、要求、結果を記録します。権限の誤りが見つかったら、何が見えたか、何が変わったか、影響する顧客は誰かを残し、同じ条件で再試験します。
新しい顧客、役割、連携機能を追加すれば、以前の合格範囲も変わります。公開時の一度の試験を、その後の変更へ自動的に流用しません。
Base44の報告から言えることを限定する
Wizは2025年、非公開アプリへの不正な登録・アクセスにつながり得るBase44の基盤側の欠陥を報告 しました。同報告では、提供者が通知から短時間で修正し、Wizが修正を確認したこと、公表時点で悪用の証拠はないとWixが説明したことも記されています。
この報告から、自社アプリに顧客間の認可不備がある、顧客情報が実際に流出した、利用者が作ったコードが原因だった、と結論づけることはできません。確認されたのは提供基盤の認証に関わる欠陥です。
一方で、提供基盤の認証と、自社アプリ内の認可は、どちらも顧客向け提供の境界に関わります。片方の修正や試験を、もう片方の合格へ読み替えない。この区別を持ち帰る材料にはなります。
NISTのSecure Software Development Framework は、設計、レビュー、実行コードの検証、部品の来歴、公開後の脆弱性対応を扱う任意の枠組みです。AIで作ったアプリ固有の安全証明ではありません。変更のたびに境界を確認し直す工程を考える参考になります。
他の人へ共有する前に、許す操作と拒む操作を確かめる
情報の見える範囲が異なる人へ共有する前に、次の条件を確かめます。顧客向けなら顧客間、社内向けなら部署や担当案件の境界として読んでください。
- 顧客、役割、情報、操作を対応させた権限表がある。
- 一覧から管理操作まで、許可と拒否を実利用者に近い条件で試している。
- 権限の付与、変更、削除の承認者と、異動・退職時の期限が決まっている。
- 誤閲覧や誤更新の疑いがあるとき、止める操作、調べる記録、連絡する担当がある。
条件が欠ける間は、試験用データによる画面確認や、単一組織に閉じた検証へ戻します。顧客数を増やす、管理者権限を広げる、従来の確認を外す判断は保留します。
再開はログインの成功ではなく、誰が何を見て変えられ、誰が境界を確かめたかを説明できる状態で決めます。
できた操作だけでなく、権限のない操作が拒まれた結果を残す
共有する前に、試験アカウントAが自分の記録を開けた結果の隣へ、権限のないBの記録は開けなかった結果を置いてください。試し方が分からなければ、権限表と確認済みの操作を添えて支援を頼みます。できた操作だけで終えず、できてはいけない操作も拒まれたかを残してください。