事例研究8 - VanArsdel, Ltd
背景
VanArsdel, Ltd.は、グローバルなオフィス用品会社です。本社はカナダにあり、世界中に小売店を展開しています。同社は、店舗、販売代理店、サプライヤー、配送サービスをサポートするために、複数のクラウドベースのソリューションを開発中です。
現在の環境
企業ウェブサイト
同社は、http://www.vanarsdelltd.com に公開ウェブサイトを提供しています。このウェブサイトは、React JavaScript のユーザーインターフェース、HTML、CSS、画像アセット、および Azure Functions でホストされている複数の API で構成されています。
小売店の所在地
同社は世界中の数千もの店舗をサポートしています。各店舗は在庫管理、購買、配送サービスをサポートするため、1時間ごとにデータをAzure Blobストレージアカウントに送信しています。
各レコードには、場所識別子と販売取引情報が含まれています。
要件
アプリケーションコンポーネントは、以下の要件を満たす必要があります。
企業ウェブサイト
SSLを使用してウェブサイトを保護してください。
- データストレージとホスティングにかかるコストを最小限に抑える。
- 継続的インテグレーションおよび継続的デプロイメント(CI/CD)のためのネイティブなGitHubワークフローを実装する。
ウェブサイトのコンテンツを、各地域での利用を目的として世界中に配信する。
- Application Insightsと可用性Webテスト(SSL証明書の有効性およびカスタムヘッダー値の検証を含む)を使用して監視を実装します。
ウェブサイトの稼働率は99.95%以上でなければなりません。
小売店の所在地
Azure Functions は、データが Blob ストレージにアップロードされたらすぐにデータを処理する必要があります。Azure Functions は、ネイティブ SQL 言語のクエリを使用して Azure Cosmos DB を更新する必要があります。
- 毎晩、店舗の販売取引情報を監査し、データの検証、売上財務処理、在庫照合を行う。
配達サービス
- Azure Functions を使用して、サービステレメトリデータを Azure Cosmos DB に保存します。データには、アイテム ID、配送車両のナンバープレート、車両のパッケージ容量、および車両の現在位置座標を含める必要があります。
- 企業ウェブサイトから呼び出されるAzure Functionを使用して、配送ドライバーのプロファイル情報をAzure Active Directory(Azure AD)に保存します。
在庫管理サービス
同社は、在庫処理用のAPIを開発するために第三者と契約を締結した。このAPIは、小売店舗のストレージアカウント内の特定のデータブロックへのアクセスを3か月間必要とし、そのデータへの読み取り専用アクセスも含まれる。
安全
- すべての Azure Functions は、企業が提供する RSA-HSM キーを使用して暗号化された、さまざまな環境および地域向けの構成データの管理と配布を一元化する必要があります。
認証と認可にはAzure ADを使用する必要があり、サービスは可能な限りマネージドIDを使用する必要があります。
問題
小売店の所在地
- 予期せぬ偶発的なデータ削除により、小売店舗の位置情報データを特定の時点に復元する必要があります。
- Azure Function からの Azure Cosmos DB クエリは、要求ユニット (RU) の使用率が高く、関数アプリのスケーリング時に大きなアイテムに対して高いポイント読み取りレイテンシを示す複数の複雑なクエリを含んでいます。
質問
ホットスポットに関する質問
配達ドライバーのプロフィール情報を確実に特定する必要があります。
システムはどのように設定すればよいですか?回答するには、回答欄で適切なオプションを選択してください。
注:正解ごとに1ポイントが加算されます。

正解:

Explanation:
Box 1: ID
Scenario: Store delivery driver profile information in Azure Active Directory (Azure AD) by using an Azure Function called from the corporate website.
ID token - A JWT that contains claims that you can use to identify users in your application. This token is securely sent in HTTP requests for communication between two components of the same application or service. You can use the claims in an ID token as you see fit. They're commonly used to display account information or to make access control decisions in an application. ID tokens are signed, but the're not encrypted. When your application or API receives an ID token, it must validate the signature to prove that the token is authentic. Your application or API must also validate a few claims in the token to prove that it's valid.
Depending on the scenario requirements, the claims validated by an application can vary, but your application must perform some common claim validations in every scenario.
Box 2: Oid
Oid - The immutable identifier for the "principal" of the request - the user or service principal whose identity has been verified. In ID tokens and app+user tokens, this is the object ID of the user. In app-only tokens, this is the object ID of the calling service principal. It can also be used to perform authorization checks safely and as a key in database tables. This ID uniquely identifies the principal across applications - two different applications signing in the same user will receive the same value in the oid claim.
Reference:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/tokens-overview
https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens