ログインできれば安全？認証と権限管理の違いを、顧客管理アプリで学ぶ。

「誰か分かる」と「そのデータを見てよい」は別の確認です。架空の顧客管理アプリを例に、データ単位の権限チェックとテストの考え方を解説します。

ログイン画面があり、パスワードも必要。それでも、別の利用者の情報が見えてしまうことがあります。原因のひとつは、「ログインした人か」は確認していても、「その人に、この情報を見せてよいか」を確認していないことです。

この記事では、開発を依頼する担当者や、Webアプリをつくり始めた方に向けて、認証と権限管理の違いを説明します。例に使う会社・利用者・データはすべて架空です。

1. 認証は「誰か」、認可は「何をしてよいか」

認証は、利用者の身元を確かめることです。認可は、その利用者に操作を許してよいかを判断することです。ここでは認可を、権限管理の中心となる仕組みとして扱います。この区別は OWASPのAuthorization Cheat Sheet でも説明されています。

例えば、営業担当の青木さんと、経理担当の井上さんが同じ社内システムにログインできるとします。二人とも本人確認はできています。しかし、顧客の連絡先、請求情報、従業員の給与まで、二人に同じ範囲を見せてよいとは限りません。

「ログイン済み」という条件だけでは、部署・担当・操作の目的の違いを表せないのです。

架空の顧客管理アプリで、青木さんの担当を顧客A、井上さんの担当を顧客Bとします。画面の一覧には、それぞれ自分の担当だけが表示されます。一見、権限管理ができているように見えます。

ところが、顧客の詳細を返すサーバー側の処理が「ログインしていれば、指定された顧客を返す」という作りだと、一覧の制限を経由しないリクエストに対応できません。対象の顧客を取得するときにも、利用者との関係を確かめる必要があります。

データを指すIDなどを受け取った際に、対象への権限確認が欠けている問題は、IDORと呼ばれます。IDを推測しにくい長い文字列に変えても、アクセスを許可してよいかという確認自体は必要です。OWASPのIDOR解説

実装前に、次の三つを一組として整理すると、確認すべき条件が見えてきます。

このアプリのルールを「担当営業は自分の顧客を閲覧・編集できる。上長は自チームの顧客を閲覧できる。削除は管理者だけ」と決めたなら、その組み合わせをそのまま確認項目にできます。

閲覧できるから編集もできる、という扱いにはしません。また、別会社の利用者が同じシステムを使う場合は、会社の境界も条件に加えます。役職名だけを見ていても、所属先が違えば許可できない操作があります。

画面側で不要なボタンを隠すことは、誤操作を減らすために役立ちます。ただし、実際にデータを返したり書き換えたりする側でも、権限を判断します。OWASPは、権限をリクエストごとに確認し、明示的に許可されない操作を原則として拒否する考え方を示しています。権限確認の推奨事項

例えば、編集ボタンがなくても、保存用の処理に編集権限の確認がなければ、画面を隠しただけです。逆に、サーバー側で拒否できていても、押せない操作を画面に並べると利用者は迷います。使いやすい画面と、権限を守る処理の両方を用意します。

自分が管理する検証環境に、異なる担当範囲のテスト用アカウントと架空データを用意します。確認するのは、想定どおり使える場面だけではありません。

一つの画面で成功した結果を、別の入口にも当てはめないことが大切です。外部のサイトや他社の本番データを使って試すものではありません。

仕様書に「ログイン機能あり」とだけ書かれているなら、一歩進めて、「誰が、どの情報に、何をできるか」を確認してみてください。担当替えや退職、契約終了など、権限が変わる場面も対象です。

まず一つのデータを選び、閲覧・編集・削除のルールを書き出す。そのうえで、許可する例と拒否する例を一つずつ用意する。この作業だけでも、「安全そう」という印象を、確認できる仕様に変えられます。

なお、ここで扱ったのはアクセス制御です。パスワードやセッション、入力処理などの問題は別途確認が必要で、この確認だけでアプリ全体の安全性を判断することはできません。

この記事の発信者DiluNova株式会社