アクセス制御による信頼の構築
多くのアプリは、ログインページがあるだけで安全だと思い込んでいます。
ログインは最初のステップに過ぎません。ユーザーがログインした後、一つの問いに答えなければなりません。「このユーザーは何ができるのか？」
多くの人が「認証（Authentication）」と「認可（Authorization）」を混同しています。
• 認証は「あなたは誰ですか？」と問いかけます。 • 認可は「あなたは何をすることを許可されていますか？」と問いかけます。
ユーザーがログインに成功したからといって、そのユーザーがすべてのレコードを見たり、すべてのプロフィールを編集したりできるわけではありません。
ルールを明確にするために、ロールベースアクセス制御（RBAC）を使用しましょう。
RBACは、ユーザーのロールを許可されたロールのリストと照合することで機能します。アクセス制御を使用しない場合、以下のようなリスクに直面します。
- ダッシュボードの露出過多
- 過剰な内部権限
- 偶発的なデータ漏洩
- 不十分な監査証跡
- 信頼の喪失
「最小権限の原則」に従ってください。ユーザーには、業務に必要なアクセス権のみを付与します。
• サポートスタッフは、すべての顧客レコードを見るべきではありません。 • エンジニアは、デフォルトで本番環境へのアクセス権を持つべきではありません。 • 人事データは分離されていなければなりません。 • 管理者ロールは限定的であり、監査可能である必要があります。
ロールだけでは不十分な場合もあります。アクションベースの権限が必要です。例えば、ユーザーはレコードを「閲覧」することはできても、「削除」はできないといった具合です。これにより、きめ細かな制御が可能になります。
また、データの機密性によってデータを分類すべきです。 • 公開データ：名前、写真 • 非公開データ：メールアドレス、電話番号 • 機密データ：給与、ID番号
コード内でこれらのカテゴリを区別して扱うことで、セキュリティ管理が容易になります。
信頼には説明責任（アカウンタビリティ）も必要です。誰かが機密データに触れるたびに、システムは監査証跡を作成しなければなりません。機密性の高いアクションには、必ず痕跡を残すべきです。
アプリをリリースする前に、以下の点を確認してください。
- ログインとセッションのフローは安全ですか？
- 権限はロールとアクションに基づいていますか？
- 機密データは分離されていますか？
- デフォルト設定は制限的ですか？
- すべてのアクセスをログに記録していますか？
- ユーザーに対して権限の内容を説明できますか？
認証はユーザーを招き入れ、認可はシステムの信頼性を維持します。信頼は、製品の機能なのです。