Azure API Management作ってみた
Azure API Management のドキュメント - チュートリアル、API リファレンス | Microsoft Docs
Azure Functions のドキュメント | Microsoft Docs
これを読みながら作成したけど、、、おそるべきわかりにくさ。
現状の理解
正確じゃないところもあるかと思いますが、ご愛嬌。
API ManagementはAPI 呼び出しのゲートウェイ。
主な設定の流れは以下の通り。
- API Managementを作成
- FunctionsやWeb Appsを関連付け(以降関連付けたAPIを"バックエンドAPI"と呼ぶ)
- バックエンドAPIへの全APIもしくは個別APIごとにProduct(製品)(1)・ポリシー(2)を設定
※このオペレーションっていうのは、GET POST PUT POST DELETEなど
※要検証だがスコープの狭い個別設定のほうでオーバーライドすると思われる。
(1) Product(製品)
ユーザーと権限を紐づけたプロファイル
(2) ポリシー
下記箇所にそれぞれポリシーを適用可能
- inbound：バックエンドへリクエストする前のポリシー
- backend：バックエンドで処理する前後(?)でのポリシー
- outbound：バックエンドからのレスポンスへのポリシー
- on-error：エラー時のポリシー
呼び出しのURLってどうなってる？
APIM⇒Functionsという構成の場合
- APIMゲートウェイのURL(APIM⇒設定⇒プロパティから確認可能)
⇒ https://(APIMの名称).azure-api.net
- FunctionsのURL(Functionsから確認可能)
⇒ https://(Functionsの名称).azurewebsites.net/
- APIMゲートウェイとFunctionsを組み合わせるとURLがどうなるかというとパスにそのまま(Functionsの名称)がくっつくんですねぇ。
⇒ https://(APIMの名称).azure-api.net/(Functionsの名称)/(Functionsのサービス)
週末のタスク整理
週末のタスクの整理！
■アクセス経路 自端末 ⇒ Application Gateway ⇒ API Management ⇒ （ Functions ⇒ Service Bus ⇒ Azure SQL Database ）
AzureとSSL通信するときの手順がわかっていないので、事前に検証しておこうと思います。 （ ）内のタスクは年末年始の宿題にしようかな… C#書ければさくっとやれそうな気がするので、意外に楽なんじゃないかと。
APIMっていうのが、得体が知れなくて、一般的にインスタンス1つでVIPを大量に用意するのか、 インスタンス1つにVIP1つ⇒すべてアプリケーションのパスベースのルーティングでカバーするのか。
SSLとあわせてAPIMの検証を週末の課題にしようと思います。
～おしまい～
こんな使い方よく思いつくな
HDDを盗んで売ってみたりするなんていう、とんでもねぇやつがいるもんだと思ってましたが、この記事の内容もなかなか。。
驚きレベルでいうとここ数ヶ月では断トツです。
ちょっと読みづらいけど、是非。
Azure VNET パート1
Azure VNETがわかんない。とおもって検索していた時に見つけたサイトで驚き。
なつかしさこみ上げる、vSwitchという単語。
VNET間の通信は妖精さんが勝手につながるようにしてくれるに思い込んでいたんですが、 裏側はこの仕組みだったのか～という驚き。
2年位前にVMwareのvSwitchやらVTEPを利用したL2延伸(VXLAN)をやるというプロジェクトをやっておりまして、 一生懸命ネットワークの論理構成図を書いたのを思い出しました。
ネットワークAと延伸したネットワークA'が会話するためには、VTEPを経由してカプセル化と非カプセル化を行います。 この時のMACアドレスはNSXコントローラが持つよ。などなど
なつかしさとともに、クラウドという言葉によって、根本的な技術から目を背けていたんだなぁと気が付くことができました。このサイトに感謝。
次回はそもそもVNETってどういう単位で分割すべきなのかということに着目して勉強したいと思います。オンプレミスの環境だと、セグメントを分離するぐらいしかやらないじゃないですか。VNETの分離ってどういう設計思想の元やればいいのかぴんとこない。
外部公開サーバをAzureに用意する
NPO日本ネットワークセキュリティ協会（JNSA）より、外部公開サーバに関する基準
https://www.jnsa.org/policy/gaibukoukai_server.pdf
- 本日のお品書き
- 1. ネットワークの分離の考え方
- 2. LBとしてApplication Gatewayを利用しようとしているが、Firewall必要？
- 3. Application Gatewayってどこまでの機能が備わっている？DNATもできるんかいな。
- 4. 最終構成
本日のお品書き
- ネットワークの分離の考え方
- LBとしてApplication Gatewayを利用しようとしているが、Firewall必要？
- Application Gatewayってどこまでの機能が備わっている？DNATもできるんかいな。
- 最終構成
1. ネットワークの分離の考え方
こういった話で真っ先に登場するのがDMZ Azureでこの考え方を適用しようとすると、DMZ専用のVNETを構築してそのVNETのNSGにてインバウンドとアウトバウンドのアクセスをコントロールする。 そうなるとフロントにAzure Firewallを置く必要があるのか。Application Gateway WAFもいらないのか。
ここまでの脳内システム構成 一般ユーザー ⇒（インターネット）⇒ Azure Firewall ⇒ VNET(NSG) ⇒ LoadBalancer ⇒WEBサーバ ⇒VNET(NSG) ⇒ DBサーバ
2. LBとしてApplication Gatewayを利用しようとしているが、Firewall必要？
Application Gateway WAF と Azure Firewall の違いは何ですか? Web アプリケーション ファイアウォール (WAF) は、一般的な脆弱性やその悪用から Web アプリケーションの受信保護を一元的に行う Application Gateway の機能です。 Azure Firewall は、非 HTTP/S プロトコル (例: RDP、SSH、FTP など) の受信保護、すべてのポートとプロトコルに対する送信ネットワークレベルの保護、送信 HTTP/S に対するアプリケーションレベルの保護を提供します。
WAFの機能はAzure Firewallにはないからね。SQLインジェクションやらクロスサイトスクリプティングへの脅威に対しては、Application Gateway WAFが必要と。
ここまでの脳内システム構成 一般ユーザー ⇒（インターネット）⇒ Application Gateway WAF(LB兼Firewall) ⇒ VNET(NSG) ⇒ WEBサーバ ⇒VNET(NSG) ⇒ DBサーバ
3. Application Gatewayってどこまでの機能が備わっている？DNATもできるんかいな。
ネットワーク セキュリティ グループ (NSG) と Azure Firewall の違いは何ですか? Azure Firewall サービスは、ネットワーク セキュリティ グループの機能を補完します。 全体で、優れた "多層防御" ネットワーク セキュリティを実現します。 ネットワーク セキュリティ グループには、分散ネットワーク レイヤーのトラフィック フィルター機能があり、この機能によって各サブスクリプションの仮想ネットワーク内のリソースに対するトラフィックを制限します。 Azure Firewall は、完全にステートフルな一元化されたネットワーク ファイアウォールです。さまざまなサブスクリプションと仮想ネットワーク全体にネットワークレベルとアプリケーションレベルの保護を提供します。
これじゃわからん。
https://cloud.nissho-ele.co.jp/blog/azure-firewall/
Azure Firewallが持つネットワーク機能は主に次の2つ(A,B)です。 A. NAT機能 Source-NAT Azure Firewallから外部へ送信されるトラフィックは自動的にAzure FirewallのパブリックIPへ変換します。 Destination-NAT Azure FirewallパブリックIP宛の通信を仮想ネットワークのプライベートIPへ変換します。
どこまでがPublicIPでどこからがPrivateIPなのかは意識しないといけないのか。なるほど。
Application GatewayもDNATはできるのね。Application Gatewayを入れるならFirewall不要説か。
クライアントのソースIPが単一IPにNATされるので、複数クライアントからの接続でもソースIPがバックエンドのサーバからは単一のクライアントと見えてしまい、ソースIPでクライアントを識別することができない。
これは注意しないといけないな。XFF使うなりしないとログ解析が難しくなりそう。LB方式はCookieにしないとだめと。
B.トラフィックフィルタリング ネットワークルール 宛先とソースのIPアドレス、ポート番号、プロトコル(TCP/UDP/ICMP)をもとに、トラフィックをフィルタリングできます。
Application Gatewayのサービス概要を見てもどうやらできない模様。 以下のようなシステム構成が描けるということは、インターネット側もNSGで制御してそのあとの通信をApplicationGatewayで受けられるということなのかな。
4. 最終構成
最終的な脳内システム構成 一般ユーザー ⇒（インターネット）⇒ VNET(NSG)&Application Gateway WAF(LB兼Firewall) ⇒ VNET(NSG) ⇒ WEBサーバ ⇒ VNET(NSG) ⇒ DBサーバ
ちなみに、IPベースでAPIごとに割り振りしようとするとかなーーーりめんどくさそう。（以下、参考サイト） tech.opst.co.jp
～おしまい～
TLS1.0からTLS1.2への変換 完結編？
（左がTLS1.0さん、右がTLS1.2ちゃん）
Apache NginxをProxyとして利用してプロトコルを変換できないかと考えていた話の続きです。
なんと、Stack Overflow（スタックオーバーフロー）で回答見つかりました！ しかも特に何か設定などもいらなそう。。。
client(TLSv1.0) --> apache(performs handshake with client with TLSv1.0) (redirects request to server, performs handshake with server with TLSv1.2) --> server(TLSv1.2).
（当然なんですけど…）Apacheまで到達したSSLリクエストはそこで復号されてしまうですよ。 だから、ApacheとそのバックエンドのAPサーバとSSL通信したければ、そのAPサーバにHTTPSでリダイレクトすればよい。
というわけでロジック解説。※未検証
①client(TLSv1.0) --> apache(performs handshake with client with TLSv1.0)
クライアント（PC端末などのブラウザ）と中間のApache（Proxyサーバ）が、まずSSLハンドシェークを行い、暗号レベルを決定する。 この時にクライアント側のCipherListでTLS1.0が最も強い暗号レベルだった場合はそれに決定。
SSLのためのサーバ証明書と秘密鍵はApacheに投入して、そのサーバ証明書を確認するためのroot証明書/中間証明書はブラウザに設定。
②apache(redirects request to server, performs handshake with server with TLSv1.2) --> server(TLSv1.2)
①の電文がApacheに到達したときには復号済みのデータとなっている。そのあとに暗号化するか平文にするかはリダイレクト先次第。
ここでAPサーバのコンテンツのパスに向けてリダイレクトしてあげれば、①と同様にSSLのハンドシェークが行われてめでたしめでたしと。 （apacheとAPサーバは最新バージョンで用意すれば、自動的にTLS1.2になると思われる）
時間が取れれば、検証までやるようにします。。（汗
～おしまい～
TRiECHOESって知ってます？
最近のYoutubeぶらり散歩の流行りは、楽器演奏。
感傷的な気持ちに浸るために探してた時に見つけたユニット TRiECHOES
もし、、もし、、生で聞けるような機会があれば是非足を運んでみたいと思います。
評価する記事はいくつもありますが、公式に活動している情報は見当たらないですね～。 今後の活躍が楽しみなグループです。
～おしまい～
