認証認可・ID管理の設計以前について

ビジネスを含めたリスクの分析はMUSTである。本稿は、この認識から出発して、認証認可設計についてどのような考慮・想定・態度形成をすればよいかのラフスケッチを行う。

ビジネスを含めたリスク分析とは、想定されるインシデントが事業継続に対してどこまでの影響を与えるのかを考慮し、そのリスク程度を認知しておく活動を指している。

例えば、（認証認可に限らないが）重大な脆弱性が見逃されたり実際に攻撃が成立したりなどの完全アウト事案が起きると、自社の開発体制全体への疑問・懸念が（パートナー企業を中心に）発生してしまうため、単一サービスへの影響では済まないだろう。

そして、「サービスを跨いで全社的な信用毀損のリスクがある」というような分析結果からは、「サービス単位を超えた影響があるセキュリティリスクについては、個別のサービス開発チームでレビューが閉じてはいけない」という帰結が得られる。これは、第三者（社内セキュリティ部署・別の開発チーム・脆弱性診断業者など）からのレビューを受ける意思決定に繋がるだろう。

また、認証認可設計という出来事そのものに目を向けると、

立ち上げ・ピボット毎に生じ得る問題である

設計・実装の難度が高い

インシデントのビジネス影響が大きすぎる

といった要素抽出ができる。仮にあなたが新規事業開発を頻繁に行うエンジニアメンバーだとするなら、認証認可についての最低限の知識は持ち合わせておかなければならない。この見解は、ほとんど自然導出的に現れるものだろう。

ドキッとした人は勉強しよう。俺も勉強するから。

技術選定（認証認可方式・IDaaS利用等に関わる意思決定）に際しても、「他所ではこのくらいの工数でできたから、今回のIDaaS・うちの体制でもそのくらいでできるだろう」といった形での見積もりや設計を行ってしまうと、考慮漏れの懸念が強まる。他所での知見を過度に信頼する態度は、サービス文脈・人員文脈・外部文脈の軽視と隣り合わせである。参考程度に留め、持ち出しすぎないこと。もちろん、あなたが認証認可・ID管理のエキスパートであるならその限りではない。

そして、単にセキュリティの分析だけでなく、ユーザープールのストック・データ活用にまつわる長期的な戦略も立案しておかなければならない。さもなくば、ビジネス的に大きな機会損失に繋がりかねない。

認証認可、難しすぎる（結論）