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

今回は「ヨドバシの中の人が語る、開発中のヨドバシAPIが目指す機能、仕組み、そしてセキュリティ（後編）」についてご紹介します。

関連ワード （共有、品質、認識等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

ヨドバシカメラは現在、お客様との接点をドメインとして設計する新たなAPIを開発中であることを、クリエーションラインが主催し10月27日に開催されたイベント「Actionable Insights Day 2023」で明らかにしました。

REST APIとして実装される予定のこのAPIについて同社は「ヨドバシスタッフの魂を注入する」としており、厳重なセキュリティやユーザーフレンドリーで高い利便性などが追求されています。

ヨドバシAPIがどのように設計され、開発、実装されていくのか。その中味が紹介されたセッションの内容を見ていきましょう。

本記事は前編と後編の2本の記事で構成されています。いまお読みの記事は後編です。

認証強度のレベルダウンを最小限にするための方法

ただ、我々はお客様の情報を大切に守ろうとしておりますので、レベルダウンを最小限にしようとあがいておりまして、そこで採用しましたのが「OpenID Connect Dynamic Client Registration」です。

これはクライアント認証をやるんですが、そのときに「private_key_jwt」を採用しています。private_key_jwtは秘密鍵で証明する方式で、その秘密鍵はハードウェアの中で安全に保存されています。

ちょっと無理があるかもしれないんですが、これで我々としてはAAL 2以上、AAL 3未満といったところで、AAL 2.2ぐらいもらえないかなと思っております。

認可にはOAuth 2.0を採用、さらに所持証明を付加

次は認可の話に移ります。

ヨドバシAPIは多くの方々に使っていただけるように考えております。特殊な手法を使ってしまうとそういうことができませんので、認可にはごく一般的な仕様である「OAuth 2.0」を採用しています。

認証と認可との分離を目的に認可コードフロー（RFC 6749 section-4.1）としました。認可後、OP（OpenID Provider）から認可コードが発行されて、認可コードと引き換えにアクセストークンを取得します。以降はAPI呼び出しのときにこのアクセストークンをサーバー側に提示し、リソースサーバー側でトークンの検証を行い、API利用を許可します。

さらにお客様の大切なリソースをもっと強く保護したいと考えると、危険なのはアクセストークンが誰かに盗まれた場合です。

ならば、盗まれたアクセストークンを使えなくすればよいと考えました。

その対策は2つ。1つ目は、アクセストークンの有効期限を短くする。2つ目は、アクセストークンだけでは使えなくする。

2つ目の実現のために、所持証明（Proof of Possession）を付加することにしました。具体的には「DPoP」（RFC9449: OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer）と呼ばれる仕組みを採用しています。

これはOPで認可コードからアクセストークンを引き替える際、DPoPの公開鍵もOP側に登録をしてもらいます。API呼び出しのときにはこのDPoPの秘密鍵による署名と取得済みのアクセストークンを組み合わせて提示をしていき、秘密鍵による署名には同じものが使えないという仕組みがあります。

ですので、この署名を盗み取られたとしてもリソースサーバが不正を発見できるため、リプレイ攻撃はできません。そのため、アクセストークンを奪われても再利用できない、といったことを実現しております。

開発生産性向上のための5つの取り組み

こうしたAPIの開発をどういった形で進めているのかについてお話をさせていただこうと思います。 我々は開発の生産性向上について5つの取り組みをしております。

その1はAPIの標準規約の策定です。メンバーのスキルのミスマッチですね。これはあるものだということで前提に考えております。人材不足の状況ではもう特にそうだと思っております。

弊社のAPI標準規約では中核的なRFCから抽出したエッセンスを記載するようにしています。このことで間違いのない無駄のないガイドを開発者に示すことができています。

これまでの経験では、APIごとの微妙な違いが設計者の認識によって生まれるケースがありました。例えばレスポンスできるリソースがなかった場合に何を返すのか。

ある人は正常なレスポンスコード「200」を返してレコードの件数が0件でしたという設計をする人もいます。

一方でリソースがなかったのでレスポンスコード「404」を返す設計者もいます。こういった些細なことでも定義を先に示しておくことで設計者の悩む時間を削減し、前向きに開発が進められることを実現しております。

APIのデザインツールやカタログを導入

生産性の向上への取り組み、その2として、APIのデザインツールを導入しています。 APIの標準規格があっても、ルールを100%正確に実施できるという人はいません。

そこでデザインツールを導入して開発のガイドをしたり、辞書機能によって定義済みの項目名を再利用したり、自動チェックなどの仕組みを入れて、開発の高速化、品質の安定化を実現しています。

その3として、APIカタログを導入しています。

なぜAPIカタログを入れてるかといいますと、ステークホルダー間の合意が非常に重要になってきます。後日、こんなものを作りたくなかったんだといった話にならないように事前にですね、設計をしながらステークホルダーと私達はお話をしています。

APIカタログを使うことで開発者とステークホルダーとが同じゴールを目指しているんだということを常に共有しています。

別ドメインの開発チームもこのAPIカタログを参照するだけで内容がわかりますので、問い合わせをすることなく開発を進めることができる。

これによって各チームの干渉というものがなく、自分の領域に集中して開発を効率よく進めていけるのです。

その4として、APIのジェネレーターも導入しています。我々の開発のパイプラインは設計から始まっています。

APIの設計を行い、チェックを自動化し、ソースコードの生成も自動化しています。生成されるソースコードの対象はAPIのクライアント、APIのサーバーです。さらにデータベースの定義（DDL）も生成可能です。 その5、最後になりますが、自動ゼロトラスト化も実現をしています。

APIサーバーをデプロイする際にNIST SP 800-207のPEPを自動的に付与する仕組みを導入しています。自動付与するものは正確にはデバイスエージェント／ゲートウェイモデルのゲートウェイに相当するところです。

経営層も技術者と同じ目線でプロジェクトを進めている

ヨドバシカメラでは、昨年お話させていただいたように、プライベートクラウドを作るところから始めて、今日ご紹介したようなAPIなどもアーキテクチャ設計からやっています。認証認可の仕組みもゼロから作っています。

技術者にとってはとても面白い環境、面白い経験ができると考えております。

我々はビジネスを想像し、ドメイン設計を進めることで新しいビジネスの輪郭を描くということをやっております。

そしてドメイン設計にはドメインエキスパートとの語らいが必要になってきますが、このドメインエキスパートとして経営層も必ずここに加わることになっています。

我々は常に経営層と直接話をしていますし、経営層も我々技術者と同じ目線でプロジェクトを進めています。

ヨドバシのビジネスを一緒に進めてくれる、そんな方を我々は募集しております。

ヨドバシカメラとヨドバシリテイルデザインはタッグを組みまして、面白い取り組みや、お客様に便利に使っていただけるサービスを日々リリースしてまいります。ありがとうございました。

関連記事

ヨドバシカメラは昨年、プライベートクラウドを内製していることを明らかにしていました。

• ヨドバシの中の人が初めて語る、ヨドバシ.comを支える内製プライベートクラウドの中身