ヨドバシの中の人が語る、開発中のヨドバシAPIが目指す機能、仕組み、そしてセキュリティ（前編）（2/2 ページ）

[新野淳一，ITmedia]

エスパーのような形で商品の提案ができる

　そこで技術的には「CQRS」（Command and Query Responsibility Segregation：コマンドクエリ責務分離）を採用します。

　そしてクエリをユースケースに合わせて用意することで、絶妙な提案を実現しようとしております。例えば、まるでエスパーのようにお客様のご要望やニーズを深く理解し、ご来店のたびに適切な商品を提案する、といったようなことです。

　これをAPIで表現するとどうなるか。

　まず、ご購入いただいたところからコマンドが発行されまして、コマンドのドメインモデルにデータが入ってきます。

　その後、ユースケースに応じてクエリモデルが生成されまして、それぞれのご提案といった形のデータが出来上がっていく。

　これを適切なタイミングで顧客の方にご提示をすると、顧客にとってエスパーのような形で商品の紹介ができると、そういうことをAPIで実現していこうと考えております。

ゼロトラストアーキテクチャを採用

　このAPIのリソースオーナーは誰か、これは全てお客様だと我々は思っております。我々はこのお預かりしているリソースを大切に守っていく義務があると考えております。

　そこで米国国立標準研究所の標準「NIST SP800-207」に沿ってゼロトラストアーキテクチャを採用することにしております。

　ゼロトラストアーキテクチャでは7つの基本方針が示されているのですが、まとめると次の3つぐらいになるのではないかと思っています。

• リソースは必要に応じてアクセスできる
• アクセスを動的に検証する
• セキュリティ観点で監視、測定する

　この3つが満たされることが大切です。

　アクセス元であるSubject、図では右上の方にある黄色い丸、このSubjectからリソースに問い合わせをする。

　このときにPDP（Policy Decision Point：ポリシー決定ポイント）と連携してPEP（Policy Enforcement Point：ポリシー実施ポイント）が検証し、合格すればトラストゾーン、丸の中の緑色の部分に到達できます。

　そしてPEP、PDPの検証は全てモニターされるということになっております。

　我々はAPIの全てのエンドポイントにこのルールを適用させていくことを考えております。

　さらに我々は境界防衛モデルも併用し、リソースの機密レベルに応じて配置を考えることで何重にもリソースを守っていきます。

認証はAAL 3を実現、しかしパスキーの扱いに悩む

　次に、リソースを守る具体的な技術、認証と認可についてお話をさせていただきます。

　認証も米国国立標準研究所の「NIST SP 800-63B」に沿って「認証強度」のAAL 3（認証強度 最高）を選択できることを実現しております。

　AAL 1は単一要素認証、AAL 2が多要素認証、AAL 3が多要素認証で暗号鍵＋ハードウェアベースで守られる、という形になります。

　具体的には、AAL 1はパスワードによる知識認証、あるいは暗号表みたいなものを使った所有者認証もしくは生体認証のうち、どれか1つが使われてる。これが単一要素認証になります。

　この所有物認証、知識認証、生体認証から複数を組み合わせることができれば多要素認証としてAAL 2レベルになります。

　AAL 3は多要素認証の中で暗号鍵の技術が使われていて、かつ、秘密鍵がハードウェアベースできちんと守られていることが要件になっています。

　FIDO 2≒WebAuthnは、スマートフォンで生体やPINで認証し、デバイス内のセキュアなハードウェアに秘密鍵が保存されていることで、AAL 3に適合していました。

　しかし新しい仕様のパスキーが生まれました。パスキーでは利便性を優先し、Apple IDやGoogleアカウントを用いることでクラウドを経由してデバイス間で暗号鍵が同期できる仕様になっています。

　つまり秘密鍵がクラウドに送られるため、セキュアなハードウェアの中に秘密鍵が保存されているかというと疑問が出てくるわけです。すると、これはAAL 3ではなくなってしまうのか、という疑問が出てきます。

　残念ながらパスキーでクラウド経由の同期をすると、認証強度としてはレベルダウンしているのではないかと考えられます。

　後編に続きます。後編では、パスキーによる認証強度のレベルダウンを最小限にするための方法、認可にOAuth 2.0を採用したことなどが解説されています。