WEBVTT

00:00:00.060 --> 00:00:02.580
マイクロソフトナレッジナゲッツ の別のエピソードへようこそ

00:00:02.580 --> 00:00:05.540
司会のミルコピータースです 今日のトピックはほとんどの人

00:00:05.540 --> 00:00:08.340
が聞いたことはあるものの実際 に理解している人は少ないAPI

00:00:08.340 --> 00:00:10.440
です この用語はよく耳にすると思います

00:00:10.440 --> 00:00:13.280
これは自分が何を話しているのか わかっているように見せたいとき

00:00:13.280 --> 00:00:16.900
に人々が使う技術用語の一つです しかし実際にはAPIはシンプル

00:00:16.900 --> 00:00:18.660
です それはあるソフトウェアが別のソフトウェア

00:00:18.660 --> 00:00:21.140
と通信するための方法にすぎません スマートフォンがサーバーにデータ

00:00:21.140 --> 00:00:22.900
を要求します サーバーはそれを返します

00:00:22.900 --> 00:00:26.560
これがAPIと呼ばれるものです ここで20個50個または100個のAPI

00:00:26.560 --> 00:00:29.220
があると想像してみてください それぞれが異なる認証異なるレート

00:00:29.220 --> 00:00:31.820
制限ドキュメントある場合を使用 する可能性があります

00:00:31.820 --> 00:00:35.580
突然2つのアプリ間の単純な会話 から始まったものが完全な混乱

00:00:35.580 --> 00:00:38.100
に陥ります 中央管理者がいないため各チーム

00:00:38.100 --> 00:00:40.540
が車輪を再発明します あるチームは独自の認証システム

00:00:40.540 --> 00:00:42.840
を構築し別のチームは独自のログ システムを構築します

00:00:42.840 --> 00:00:46.460
セキュリティのギャップが至るところ に現れます 開発者はどのAPIが何をする

00:00:46.460 --> 00:00:49.440
のか混乱しシステム全体で実際 に何が起こっているのかを一元的

00:00:49.440 --> 00:00:51.220
に把握できません Azureアピマネジメント

00:00:51.220 --> 00:00:53.880
はこの問題を解決します 単一のコントロールセンターを

00:00:53.880 --> 00:00:57.580
提供します APIの航空完成等のような ものと考えてください

00:00:57.580 --> 00:01:00.740
このエピソードの終わりまでに それが実際に何であるかなぜ重要

00:01:00.740 --> 00:01:03.280
なのか全ての要素がどのように 組み合わさるのかが理解できます

00:01:03.280 --> 00:01:08.120
コーヒーを用意して早速始めましょう 問題はAPIが多すぎて制御できない

00:01:08.120 --> 00:01:10.260
ことです これが現代のソフトウェアの現実

00:01:10.260 --> 00:01:12.980
です 10年前はおそらく一つの大きなアプリケーション

00:01:12.980 --> 00:01:15.900
モノリス一つのデータベース 一つのAPIというシンプルな構成

00:01:15.900 --> 00:01:17.720
でした 今日では同じアプリケーション

00:01:17.720 --> 00:01:20.120
が数十のマイクロサービスに分割 されている可能性があります

00:01:20.120 --> 00:01:23.700
各サービスはユーザーアカウント 支払い在庫通知など一つの処理

00:01:23.700 --> 00:01:25.840
を行いそれぞれが独自のAPIを公開 します

00:01:25.840 --> 00:01:29.200
突然システムへのエントリポイント が1050100個もできてしまいます

00:01:29.200 --> 00:01:32.040
ここでこれらのAPIを使用するもの を構築しようとしている開発者

00:01:32.040 --> 00:01:34.100
を想像してみてください それぞれを見つけそれぞれの

00:01:34.100 --> 00:01:36.620
認証方法を検討する必要があります APIキーを使用する

00:01:36.620 --> 00:01:38.820
ものもあればオースを使用する ものもあり何も使用しないもの

00:01:38.820 --> 00:01:40.500
もあります レート制限を手動で処理しない

00:01:40.500 --> 00:01:43.300
とブロックされるリスクがあります それぞれが期待するデータ形式

00:01:43.300 --> 00:01:45.880
を理解する必要があります これは疲れる作業です

00:01:45.880 --> 00:01:49.240
運用面から見るとさらに悪化します 中央ゲートウェイがないため各チーム

00:01:49.240 --> 00:01:51.120
はセキュリティとログ記録を各自 のサービスに手動で追加する

00:01:51.120 --> 00:01:53.020
必要があります うまく行うチームもあればエラー

00:01:53.020 --> 00:01:55.740
のログ記録を忘れるチームもあります 入力の検証を全く行わない

00:01:55.740 --> 00:01:58.160
チームもあります 一貫性がなくエラーが発生しやすく

00:01:58.160 --> 00:01:59.540
セキュリティ上の悪夢が起こり かねません

00:01:59.540 --> 00:02:01.400
コンプライアンスはほぼ不可能 になります

00:02:01.400 --> 00:02:03.920
誰がいつ何にアクセスしたかを 証明する必要がありますか

00:02:03.920 --> 00:02:06.520
それぞれ独自のログ形式を持つ 20つの異なるサービスから監査

00:02:06.520 --> 00:02:09.480
証石を取得するのは大変です システムが先月処理したAPIコール

00:02:09.480 --> 00:02:10.940
の数を確認する必要があります か

00:02:10.940 --> 00:02:13.420
12つの異なるダッシュボードから メトリクスを繋ぎ合わせる必要

00:02:13.420 --> 00:02:15.140
があります 重要なのは規模が大きくなる

00:02:15.140 --> 00:02:17.440
につれてこれは単に苦痛を与える だけでなく機能しなくなる

00:02:17.440 --> 00:02:20.500
ということです 中央制御ポイント がなければ開発者サービス顧客

00:02:20.500 --> 00:02:22.720
を増やすことはできません 建物を想像してみてください

00:02:22.720 --> 00:02:24.980
すべての部屋に異なる鍵がかか っていると想像してください

00:02:24.980 --> 00:02:28.440
受付やディレクトリはありません 訪問者は正しいドアを探してさま

00:02:28.440 --> 00:02:30.740
よい歩きイライラして最終的に 諦めます

00:02:30.740 --> 00:02:33.920
完全な混乱です これがAPI管理が解決する

00:02:33.920 --> 00:02:36.340
ように設計された問題です アジュールアピマネージメント

00:02:36.340 --> 00:02:38.200
とは何ですか コントロールタワーです

00:02:38.200 --> 00:02:40.440
ではアジュールアピマネージメント とは正確には何ですか

00:02:40.440 --> 00:02:44.480
最も簡単な定義は次の通りです バックエンドAPIとそれを使用する

00:02:44.480 --> 00:02:47.520
アプリウェブサイトデバイスパートナー の間に位置するマネージドサービス

00:02:47.520 --> 00:02:49.480
です しかし重要なのは単なるプロ機種

00:02:49.480 --> 00:02:51.220
ではないということです プロ機種はトラフィックを転送

00:02:51.220 --> 00:02:53.560
するだけでそれ以上の機能はありません アジュールアピマネージメント

00:02:53.560 --> 00:02:57.800
はAPIのライフサイクル全体をカバー します 公開保護監視そして最終的には

00:02:57.800 --> 00:02:59.820
廃止します 完全なコントロールセンターです

00:02:59.820 --> 00:03:01.860
3つの主要なコンポーネントに分けて 説明しましょう

00:03:01.860 --> 00:03:05.060
1つ目はゲートウェイです これは正面玄関です アプリまたは

00:03:05.060 --> 00:03:07.380
ウェブサイトからの受信リクエスト は全てバックエンドに直接ではなく

00:03:07.380 --> 00:03:09.820
最初にゲートウェイに到達します ゲートウェイはリクエストを処理

00:03:09.820 --> 00:03:13.340
し設定したポリシーを適用し メトリックを収集し適切なバック

00:03:13.340 --> 00:03:16.320
エンドサービスに転送します 交通整理係と考えてください

00:03:16.320 --> 00:03:19.780
次は管理プレーンです ここでは全てを定義します

00:03:19.780 --> 00:03:22.880
APIポリシー製品サブスクリプション などです

00:03:22.880 --> 00:03:25.520
アジュールポータルコマンドライン またはバイセップやテラフォーム

00:03:25.520 --> 00:03:27.780
のようなインフラストラクチャーズ コードを使用してこれを行います

00:03:27.780 --> 00:03:30.660
ここは全てがどのように動作する かを構成するコントロールルーム

00:03:30.660 --> 00:03:32.720
です 次に開発者ポータルがあります

00:03:32.720 --> 00:03:36.260
これは社内外の開発者がAPIを発見 したりドキュメントを読んだり

00:03:36.260 --> 00:03:38.960
サブスクリプションキーを取得 したりブラウザでAPI呼び出しを

00:03:38.960 --> 00:03:40.840
直接テストしたりできるセルフ サービスウェブサイトです

00:03:40.840 --> 00:03:43.220
PDFをメールでやり取りする必要 はもうありません

00:03:43.220 --> 00:03:46.320
わかりやすい例えがあります 現代の空港を想像してみてください

00:03:46.320 --> 00:03:49.440
ゲートウェイは滑走路です 全ての飛行機は最初にそこに着陸

00:03:49.440 --> 00:03:51.220
します 管理機は完成塔です

00:03:51.220 --> 00:03:54.260
交通を誘導しルールを設定し全て を監視します

00:03:54.260 --> 00:03:56.640
そして開発者ポータルは情報掲示板 です

00:03:56.640 --> 00:03:59.620
パイロットは飛行前にこれを確認 し誰とも話さずに必要な全ての

00:03:59.620 --> 00:04:02.180
情報を見つけることができます ではゲートウェイにズームイン

00:04:02.180 --> 00:04:04.340
してみましょう ここはアプリが実際に通信

00:04:04.340 --> 00:04:06.520
する部分であり本当の魔法が起こる 場所です

00:04:06.520 --> 00:04:10.620
ゲートウェイはAPIの正面玄関です アプリが実際に通信するのは

00:04:10.620 --> 00:04:12.980
ゲートウェイなのでゲートウェイ について説明しましょう

00:04:12.980 --> 00:04:15.520
モバイルアプリウェブサイト iot デバイスからの全てのリクエスト

00:04:15.520 --> 00:04:18.040
はまずゲートウェイに到達しバック エンドに直接アクセスすることは

00:04:18.040 --> 00:04:19.660
ありません これが重要な点です

00:04:19.660 --> 00:04:22.280
ゲートウェイは最前線に位置し 単一のエントリーポイントとして

00:04:22.280 --> 00:04:24.140
機能します ゲートウェイはリクエストを転送

00:04:24.140 --> 00:04:27.360
する前にポリシーを適用できます ポリシーとはレート制限 ip

00:04:27.360 --> 00:04:30.720
フィルタリングヘッダー書き換え 認証チェックなどxmlまたはjson

00:04:30.720 --> 00:04:32.800
で記述するルールです これらは全てバックエンド

00:04:32.800 --> 00:04:34.800
のコードを一行も変更することなく 実現できます

00:04:34.800 --> 00:04:38.480
具体的な例を挙げましょう api に無料プランとプレミアムプラン

00:04:38.480 --> 00:04:40.720
があるとします ポリシーを使用すると無料ユーザー

00:04:40.720 --> 00:04:43.180
は1分あたり5リクエストに制限 しプレミアムユーザーは100リクエスト

00:04:43.180 --> 00:04:45.120
まで許可できます バックエンドは違いを認識する

00:04:45.120 --> 00:04:47.260
ことはありません リクエストを処理するだけです

00:04:47.260 --> 00:04:49.260
ゲートウェイがポリシーの適用 を処理します

00:04:49.260 --> 00:04:50.980
ゲートウェイはキャッシュも処理 します

00:04:50.980 --> 00:04:54.380
滅多に変更されない商品リストなど データが繰り返しリクエスト

00:04:54.380 --> 00:04:57.540
される場合ゲートウェイはレスポンス をキャッシュして直接提供できます

00:04:57.540 --> 00:05:00.760
バックエンドに一切手を加える 必要がないためレスポンスが早く

00:05:00.760 --> 00:05:03.960
なりサーバーへの負荷も軽減されます データ変換も可能です

00:05:03.960 --> 00:05:07.620
バックエンドがxmlを返す場合でも モバイルアプリはjsonを期待します

00:05:07.620 --> 00:05:09.700
ゲートウェイはオンザフライで 変換できます

00:05:09.700 --> 00:05:12.520
バックエンドもアプリも変更する 必要はありません

00:05:12.520 --> 00:05:16.180
ゲートウェイが変換を処理します また全ての呼び出し全てのリクエスト

00:05:16.180 --> 00:05:18.220
全てのレスポンス全てのエラーをログに記録します

00:05:18.220 --> 00:05:21.560
誰がいつ何を呼び出し何が起こった かの完全な監査証跡が得られます

00:05:21.560 --> 00:05:24.280
これだけでもコンプライアンスのために 導入する価値があります

00:05:24.280 --> 00:05:27.320
グローバルなユーザー層がいる場合は ゲートウェイを複数のリージョン

00:05:27.320 --> 00:05:27.940
に展開できます

00:05:27.940 --> 00:05:30.380
トラフィックは自動的に最も近い リージョンにルーティングされる

00:05:30.380 --> 00:05:33.040
ためレイテンシが低くなりエクスペリエンス が向上します

00:05:33.040 --> 00:05:35.920
もう一つゲートウェイは実際のバックエンド urlを隠します

00:05:35.920 --> 00:05:38.040
クライアントにはゲートウェイアドレス のみが表示されます

00:05:38.040 --> 00:05:40.280
バックエンドサーバーはインターネット から隠されたままです

00:05:40.280 --> 00:05:42.880
これはすぐに使える大きなセキュリティ メリットです

00:05:42.880 --> 00:05:45.080
ポリシー全てを制御するエンジン

00:05:45.080 --> 00:05:47.420
では先ほど述べたポリシーについて はどうでしょうか

00:05:47.420 --> 00:05:50.060
ポリシーはapimを真に強力にする エンジンです

00:05:50.060 --> 00:05:53.040
ポリシーはバックエンドコードに 触れることなくリクエストまたは

00:05:53.040 --> 00:05:54.280
レスポンスの動作を変更します

00:05:54.280 --> 00:05:56.320
apiのラッパーと考えてください

00:05:56.320 --> 00:05:59.960
トラフィックが流れるにつれて 自動的に追加削除または変更を

00:05:59.960 --> 00:06:00.700
行うことができます

00:06:00.700 --> 00:06:03.760
ポリシーはリクエストのライフ サイクルの4つのポイントで実行

00:06:03.760 --> 00:06:04.100
できます

00:06:04.100 --> 00:06:06.980
インバウンドリクエストがバックエンド に到達する前

00:06:06.980 --> 00:06:10.020
アウトバウンドレスポンスがクライアント に到達する前

00:06:10.020 --> 00:06:12.980
バックエンドリクエストがサービス に到達する直前

00:06:12.980 --> 00:06:15.140
およびエラー何かが失敗したとき

00:06:15.140 --> 00:06:18.680
一般的なインバウンドには呼び出し 元のIDを確認するためのjwtトークン

00:06:18.680 --> 00:06:21.180
の検証apiキーの確認urlの書き換え

00:06:21.180 --> 00:06:22.740
ipアドレスによる制限などがあります

00:06:22.740 --> 00:06:25.640
これらはすべてバックエンドが単一 のリクエストを見る前に実行

00:06:25.640 --> 00:06:25.980
されます

00:06:25.980 --> 00:06:28.360
アウトバウンドではレスポンス ボディを変換できます

00:06:28.360 --> 00:06:31.460
テキストの検索と置換機密フィールド の削除フォーマットの変更など

00:06:31.460 --> 00:06:31.960
が可能です

00:06:31.960 --> 00:06:34.400
レスポンスをキャッシュして同じ リクエストがバックエンドに到達

00:06:34.400 --> 00:06:35.440
しないようにすることもできます

00:06:35.440 --> 00:06:38.100
内部情報が漏えいするヘッダー を削除することもできます

00:06:38.100 --> 00:06:39.640
具体的な例を挙げましょう

00:06:39.640 --> 00:06:43.080
apiがあらゆる場所に青という単語 を含む製品説明を返すとします

00:06:43.080 --> 00:06:45.600
ブランド名を変更して黄色に置き換え たいとします

00:06:45.600 --> 00:06:48.600
バックエンドのコードを変更する代わり にアウトバウンドポリシーを

00:06:48.600 --> 00:06:49.320
一つ追加します

00:06:49.320 --> 00:06:51.640
青を検索し黄色に置き換えます

00:06:51.640 --> 00:06:52.800
これで完了です

00:06:52.800 --> 00:06:54.360
バックエンドは変更されません

00:06:54.360 --> 00:06:57.020
レート制限とクォータポリシー はバックエンドを不正利用から

00:06:57.020 --> 00:06:57.460
保護します

00:06:57.460 --> 00:07:00.760
誰かのアプリが暴走して1秒間 に1万回apiに攻撃を仕掛け始めた

00:07:00.760 --> 00:07:03.260
場合ポリシーが介入して速度を 落としてくださいと指示します

00:07:03.260 --> 00:07:05.240
バックエンドは健全な状態を維持 します

00:07:05.240 --> 00:07:06.460
高度なロジックが必要ですか

00:07:06.460 --> 00:07:08.560
ポリシー内にカスタムcシャープ式 を記述できます

00:07:08.560 --> 00:07:10.560
これらはパフォーマンスのためにコンパイル されます

00:07:10.560 --> 00:07:12.620
そのため実行時のコストは発生 しません

00:07:12.620 --> 00:07:15.880
ユーザーロールを検索したり動的な レート制限を計算したりリクエスト

00:07:15.880 --> 00:07:18.020
ヘッダーに基づいて条件付きで レスポンスを変換したりできます

00:07:18.020 --> 00:07:21.560
重要なポイントはポリシーを使用 するとapiを実行するコードに触れる

00:07:21.560 --> 00:07:23.800
ことなくapiの動作を制御できる ということです

00:07:23.800 --> 00:07:27.380
つまり変更が早くなりデプロイ が減りリスクが軽減されます

00:07:27.380 --> 00:07:30.880
製品とサブスクリプション消費者 向けのapiのパッケージ化

00:07:30.880 --> 00:07:34.440
これでapiが定義されポリシー が設定されゲートウェイが順調に

00:07:34.440 --> 00:07:34.980
動作しています

00:07:34.980 --> 00:07:37.360
しかし異なる顧客に異なるもの へのアクセスをどのように提供

00:07:37.360 --> 00:07:37.880
するのでしょうか

00:07:37.880 --> 00:07:39.820
そこで製品とサブスクリプション が登場します

00:07:39.820 --> 00:07:43.900
apimではapiを製品と呼ばれるもの にグループ化します

00:07:43.900 --> 00:07:45.460
バンドルと考えてください

00:07:45.460 --> 00:07:49.220
基本的なapiのみを含む無料ティア 製品を用意することができます

00:07:49.220 --> 00:07:52.400
読み取り専用アクセスのみの場合 もあり書き込み操作や管理エンド

00:07:52.400 --> 00:07:54.900
ポイントを含む全ての機能を含む プレミアム製品を用意する

00:07:54.900 --> 00:07:55.440
こともできます

00:07:55.440 --> 00:07:59.200
開発者は個々のapiを購読する のではなく製品を購読します

00:07:59.200 --> 00:08:01.520
公読すると公読キーが発行され ます

00:08:01.520 --> 00:08:04.440
実際には2つのキーが発行される ためダウンタイムなしで1つをローテーション

00:08:04.440 --> 00:08:04.680
できます

00:08:04.680 --> 00:08:07.640
このキーはその製品内の任意 のapiを使用するためのパスです

00:08:07.640 --> 00:08:09.560
公読の仕組みはあなたが制御 できます

00:08:09.560 --> 00:08:11.700
製品は承認を必要とする場合があります

00:08:11.700 --> 00:08:14.900
公読者を手動で承認することも セルフサービスで公開することも

00:08:14.900 --> 00:08:15.180
できます

00:08:15.180 --> 00:08:17.400
誰でもサインアップしてすぐに アクセスできます

00:08:17.400 --> 00:08:20.480
公読前にユーザーが同意しなければ ならない法的条件を含めることも

00:08:20.480 --> 00:08:20.780
できます

00:08:20.780 --> 00:08:23.400
apiが機密データを扱う場合は これは重要です

00:08:23.400 --> 00:08:25.500
これがapiを収益化する方法です

00:08:25.500 --> 00:08:27.060
低レート制限の無料製品

00:08:27.060 --> 00:08:28.540
1分あたり5回呼び出し

00:08:28.540 --> 00:08:30.440
より高い制限またはより多くの エンドポイント

00:08:30.440 --> 00:08:31.820
1分あたり100回の呼び出し

00:08:31.820 --> 00:08:33.220
さらにプレミアム機能へのアクセス

00:08:33.220 --> 00:08:34.560
バックエンドは気にしません

00:08:34.560 --> 00:08:37.280
ゲートウェイは呼び出し元が 公読した製品に基づいて制限を

00:08:37.280 --> 00:08:37.760
適用します

00:08:37.760 --> 00:08:39.280
実際の例を以下に示します

00:08:39.280 --> 00:08:41.440
カンファレンスアプリを構築している と想像してください

00:08:41.440 --> 00:08:42.240
セッションスケジュール

00:08:42.240 --> 00:08:43.160
スピーカーの略歴

00:08:43.160 --> 00:08:45.760
会場マップのapiを備えた参加者 向け製品を作成します

00:08:45.760 --> 00:08:49.040
次にリード生成apiも含むスポンサー 向け製品を作成します

00:08:49.040 --> 00:08:51.980
スポンサーは参加者のバッジをスキャン して連絡先情報を取得できます

00:08:51.980 --> 00:08:54.780
同じバックエンド異なる製品異なる アクセスレベル

00:08:54.780 --> 00:08:57.080
これら2つのサブスクリプション キーはローテーション用に設計

00:08:57.080 --> 00:08:57.560
されています

00:08:57.560 --> 00:09:00.280
キーが侵害された場合は新しい キーを生成します

00:09:00.280 --> 00:09:02.920
2番目のキーを使用するとサービス を中断することなく切り替える

00:09:02.920 --> 00:09:03.360
ことができます

00:09:03.360 --> 00:09:06.700
新しいキーを生成しアプリを 更新し古いキーを取り消します

00:09:06.700 --> 00:09:07.700
シームレスです

00:09:07.700 --> 00:09:12.260
開発者ポータルapi利用者のための セルフサービスapi製品を設定しました

00:09:12.260 --> 00:09:14.340
次に開発者がそれらを見つける 必要があります

00:09:14.340 --> 00:09:16.140
それが開発者ポータルの役割です

00:09:16.140 --> 00:09:19.300
開発者ポータルは全てのapmインスタンス に組み込まれたウェブサイトです

00:09:19.300 --> 00:09:23.220
開発者はこれを使用してapiを参照 しドキュメントを読みエンドポイント

00:09:23.220 --> 00:09:24.920
をブラウザで直接インタラクティブ にテストします

00:09:24.920 --> 00:09:27.520
セットアップは不要でメールのやり取り もありません

00:09:27.520 --> 00:09:29.720
ただしデフォルトでは公開されて いません

00:09:29.720 --> 00:09:32.900
apmインスタンスを最初に作成する とポータルは存在しますが誰も

00:09:32.900 --> 00:09:33.700
それを見ることができません

00:09:33.700 --> 00:09:35.660
まずカスタマイズして公開する 必要があります

00:09:35.660 --> 00:09:37.080
これは意図的なものです

00:09:37.080 --> 00:09:39.500
未完成のポータルを世間に公開 したくはないでしょう

00:09:39.500 --> 00:09:42.260
ブランドカラーやロゴをカスタマイズ したりapiドキュメントと一緒に

00:09:42.260 --> 00:09:44.300
ブログ用のワードプレスコンテンツ を埋め込んだりすることもできます

00:09:44.300 --> 00:09:47.340
会社の外観や雰囲気に合わせて 完全にカスタマイズ可能です

00:09:47.340 --> 00:09:49.140
真の価値はセルフサービスです

00:09:49.140 --> 00:09:51.980
開発者はサインアップすると サブスクリプションキーが自動的に

00:09:51.980 --> 00:09:54.360
取得されすぐにapiの呼び出しを 開始できます

00:09:54.360 --> 00:09:58.120
手動でのメール送信も承認待ち もキーの取得方法を尋ねるサポート

00:09:58.120 --> 00:09:58.820
チケットもありません

00:09:58.820 --> 00:10:02.400
開発者自身が行うためサポート の負担が大幅に軽減されます

00:10:02.400 --> 00:10:04.660
変更ログやリリースノートも公開 できます

00:10:04.660 --> 00:10:08.780
apiを更新すると開発者はポータル で予期せぬ事態なく確認できます

00:10:08.780 --> 00:10:12.080
urlを知っている人なら誰でもアクセス できるように公開することも

00:10:12.080 --> 00:10:15.380
entra idテナントのユーザーのみ に制限して組織内のユーザーのみ

00:10:15.380 --> 00:10:16.840
が閲覧できるようにすることも できます

00:10:16.840 --> 00:10:19.760
どちらのオプションも様々なユース ケースに対応しています

00:10:19.760 --> 00:10:23.080
開発者ポータルはapi管理を真の プラットフォームにするものです

00:10:23.080 --> 00:10:24.960
apiの転倒と考えてください

00:10:24.960 --> 00:10:28.020
これがないと開発者はドキュメント を検索したり周囲に尋ねたりする

00:10:28.020 --> 00:10:28.620
必要があります

00:10:28.620 --> 00:10:31.780
これにより必要なものを見つけて 構築を開始できます

00:10:31.780 --> 00:10:35.080
セキュリティー認証認可シークレット

00:10:35.080 --> 00:10:37.940
セキュリティーがしっかりして いなければこのすべての機能は

00:10:37.940 --> 00:10:38.600
役に立ちません

00:10:38.600 --> 00:10:41.740
そこでapimがidアクセスシークレット をどのように処理するかについて

00:10:41.740 --> 00:10:42.240
説明しましょう

00:10:42.240 --> 00:10:44.740
apimは複数の認証方法をサポート しています

00:10:44.740 --> 00:10:47.940
最もシンプルなのは先ほど説明 したサブスクリプションキーです

00:10:47.940 --> 00:10:51.600
しかし本番システムではオース 2ゼロjwtトークンクライアント

00:10:51.600 --> 00:10:54.260
証明書ipフィルタリングなどより 強力なものが必要になります

00:10:54.260 --> 00:10:56.960
apiの機密性に応じてこれらをレイヤー 化します

00:10:56.960 --> 00:11:00.540
本番環境ではentra idでオース 2例を使用するのがベストプラクティス

00:11:00.540 --> 00:11:00.720
です

00:11:00.720 --> 00:11:02.280
その仕組みは次の通りです

00:11:02.280 --> 00:11:05.360
クライアントアプリはentra idから トークンを取得しapiリクエストと

00:11:05.360 --> 00:11:06.020
共に送信します

00:11:06.020 --> 00:11:10.320
apimは署名発行者対象者有効期限 をチェックしてトークンを検証

00:11:10.320 --> 00:11:10.580
します

00:11:10.580 --> 00:11:14.020
トークンが有効な場合apimはトークン を含めてリクエストをバックエンド

00:11:14.020 --> 00:11:14.640
に転送します

00:11:14.640 --> 00:11:18.680
バックエンドはapimがすでに検証 済みであるためそれを信頼し再検証

00:11:18.680 --> 00:11:19.500
する必要はありません

00:11:19.500 --> 00:11:21.900
各サービスが処理しなければならない ことが一つ減ります

00:11:21.900 --> 00:11:24.000
さて秘密情報について話しましょう

00:11:24.000 --> 00:11:27.620
apiキー接続文字列証明書など はポリシーファイルやソース管理

00:11:27.620 --> 00:11:28.700
にハードコーディングしたくありません

00:11:28.700 --> 00:11:31.240
apimには名前付き値という機能 があります

00:11:31.240 --> 00:11:35.360
秘密情報はapimに一元的に保存 しポリシー内で名前で参照します

00:11:35.360 --> 00:11:37.760
実際の値はポリシーコードには 表示されません

00:11:37.760 --> 00:11:40.920
さらに良いことに名前付き値を azure keyfaultに接続できます

00:11:40.920 --> 00:11:44.240
秘密情報はkeyfaultに暗号化された 状態で保存されapimは実行時にそれら

00:11:44.240 --> 00:11:44.640
を取得します

00:11:44.640 --> 00:11:47.700
DevOpsチームを含め誰も実際の秘密 値を見ることはできません

00:11:47.700 --> 00:11:50.740
キーをローテーションする必要 がある場合はkeyfaultで更新すると

00:11:50.740 --> 00:11:52.740
apimが自動的に変更を検出します

00:11:52.740 --> 00:11:55.400
apimはマネージドidもサポート しています

00:11:55.400 --> 00:11:59.760
これによりapimは資格情報をどこにも 保存することなくkeyfaultやバックエンド

00:11:59.760 --> 00:12:01.840
apiなどの他のazureサービスに認証 できます

00:12:01.840 --> 00:12:04.880
azureがidを管理するため権限を付与 するだけで済みます

00:12:04.880 --> 00:12:08.400
またネットワーク分離のためにapim を仮想ネットワーク内にデプロイ

00:12:08.400 --> 00:12:08.680
できます

00:12:08.680 --> 00:12:10.280
これがプレミアムティアです

00:12:10.280 --> 00:12:14.720
つまりazureフロントのポイント はバックエンドサービスをインターネット

00:12:14.720 --> 00:12:19.480
に直接公開する必要がないということ ですapimは外部から見える唯一

00:12:19.480 --> 00:12:20.040
のものです

00:12:20.040 --> 00:12:23.080
この階層的なアプローチにより 多層防御が構築されます

00:12:23.080 --> 00:12:26.780
ゲートウェイでの認証金庫内の シークレットバックエンド周辺の

00:12:26.780 --> 00:12:29.800
ネットワーク分離各レイヤーが 次のレイヤーを強化します

00:12:29.800 --> 00:12:34.080
価格ティアどれがあなたに合っていますか では費用はいくらですかティアを

00:12:34.080 --> 00:12:34.820
見ていきましょう

00:12:34.820 --> 00:12:38.720
消費ティア固定月額料金なしでapi コールごとに支払います

00:12:38.720 --> 00:12:41.640
プロトタイプ作成時など少量または バースト的なワークロード

00:12:41.640 --> 00:12:42.300
に最適です

00:12:42.300 --> 00:12:44.860
まだ必要なものがわからない 場合はここから始めてください

00:12:44.860 --> 00:12:48.060
開発者ティアでは約50ドルの固定 月額料金が提供されます

00:12:48.060 --> 00:12:51.880
フル機能セットですがslaはありません 開発およびテスト環境に最適です

00:12:51.880 --> 00:12:54.260
プレミアムのすべての機能を使用 できますが本番環境では使用

00:12:54.260 --> 00:12:54.560
できません

00:12:54.560 --> 00:12:56.660
基本ティアはエントリーレベル の本番環境です

00:12:56.660 --> 00:12:59.520
スループットは低く仮想ネットワーク のサポートはありませんが実際の

00:12:59.520 --> 00:13:00.480
slaが提供されます

00:13:00.480 --> 00:13:03.620
プライベートネットワークが重要ではない 内部ツールや小規模プロジェクト

00:13:03.620 --> 00:13:04.260
に適しています

00:13:04.260 --> 00:13:06.580
ほとんどの企業は標準ティア に落ち着きます

00:13:06.580 --> 00:13:11.060
仮想ネットワークのサポート 99.95%slaおよび優れたスループット

00:13:11.060 --> 00:13:11.600
が含まれます

00:13:11.600 --> 00:13:15.160
ビジネス上重要なapiを実行している 場合はおそらくここに落ち着く

00:13:15.160 --> 00:13:15.380
でしょう

00:13:15.380 --> 00:13:18.500
プレミアムティアは最大限の信頼 性とプライベートネットワーク

00:13:18.500 --> 00:13:20.040
を必要とするグローバル企業向け です

00:13:20.040 --> 00:13:21.020
マルチリージョン展開

00:13:21.020 --> 00:13:24.220
セルフホストゲートウェイ 99.99%sla

00:13:24.220 --> 00:13:26.040
完全な仮想ネットワークインジェクション

00:13:26.040 --> 00:13:28.260
ユニットあたり月額約2700から

00:13:28.260 --> 00:13:32.260
マイクロソフトはv2ティア ベーシックv2スタンダードv2プレミアム

00:13:32.260 --> 00:13:33.180
v2も導入しました

00:13:33.180 --> 00:13:36.140
含まれているリクエストクォーター と100万ごとの超過料金で価格設定

00:13:36.140 --> 00:13:36.780
を簡素化します

00:13:36.780 --> 00:13:39.440
複数のメーターを追跡する代わり にリクエストの明確なバケット

00:13:39.440 --> 00:13:41.760
を取得し追加使用料に対して単純 な増分で支払います

00:13:41.760 --> 00:13:43.460
選択方法は次の通りです

00:13:43.460 --> 00:13:45.080
テストには開発者から始めます

00:13:45.080 --> 00:13:46.940
本番環境ではスタンダードに移行 します

00:13:46.940 --> 00:13:49.020
グローバルスケールまたはプライベート ネットワークが必要な場合

00:13:49.020 --> 00:13:50.060
はプレミアムを選択します

00:13:50.060 --> 00:13:52.740
またティアは後でいつでも移行 できることを覚えておいてください

00:13:52.740 --> 00:13:55.500
小規模から始めてニーズの変化 に応じて拡張します

00:13:55.500 --> 00:13:59.220
API管理は多数のAPIが混沌としている 状況をゲートウェイポリシー

00:13:59.220 --> 00:14:01.540
セキュリティ開発者エクスペリエンス のための単一のコントロールセンター

00:14:01.540 --> 00:14:02.080
に集約します

00:14:02.080 --> 00:14:04.700
重要なのは単なるプロキシ以上 の存在であるということです

00:14:04.700 --> 00:14:07.120
APIエコシステムの脳と神経系 のようなものだと考えてください

00:14:07.120 --> 00:14:10.580
API管理がなければ各チームが独自の認証 ログ記録レート制限を構築する

00:14:10.580 --> 00:14:10.980
ことになります

00:14:10.980 --> 00:14:14.280
結果として一貫性の欠如セキュリティ 上の脆弱性そして何が起こっている

00:14:14.280 --> 00:14:15.960
のかを一元的に把握できないという 事態に陥ります

00:14:15.960 --> 00:14:19.740
API管理を導入すればサービスごとに 車輪を再発明することなく一貫性

00:14:19.740 --> 00:14:21.500
セキュリティスケーラビリティ を実現できます

00:14:21.500 --> 00:14:23.160
簡単な演習をしてみましょう

00:14:23.160 --> 00:14:26.140
現在直接公開しているAPIを一つ 考えてみてください

00:14:26.140 --> 00:14:28.380
関数エンドポイントやアプリサービス などです

00:14:28.380 --> 00:14:32.020
API管理を全面に配置することでセキュリティ 体制や使用状況の監視能力

00:14:32.020 --> 00:14:33.140
はどのように変化するでしょうか

00:14:33.140 --> 00:14:36.000
この演習をじっくり考えるだけ でもその価値がわかるでしょう

00:14:36.000 --> 00:14:38.020
次のステップはチャンネル登録 です

00:14:38.020 --> 00:14:41.460
今後のエピソードではAPIのインポート 方法最初のポリシーの適用方法

00:14:41.460 --> 00:14:43.460
リアルタイムでの使用状況の監視 方法をご紹介します

00:14:43.460 --> 00:14:45.220
理論から実践へとステップアップ できます

00:14:45.220 --> 00:14:47.960
この情報が役に立った場合はアプリ 開発に携わっている方と共有して

00:14:47.960 --> 00:14:48.160
ください

00:14:48.160 --> 00:14:50.080
これで彼らは何ヶ月もの悩み を解消できるでしょう

00:14:50.080 --> 00:14:51.080
聞いてくれてありがとう