OCIのロードバランサーにHTTPSとWAFを付け、社内アプリを外出先から安全に使う
※当ページにはAmazonアソシエイト等の広告リンクを含みます。
公式ドキュメントで検証最終検証 2026-11-01編集部出典 17件
当ページの解説・制限値・構成図は、一般公開されている Oracle Cloud Infrastructure (OCI) 公式ドキュメント、Oracle Cloud Price List、および Oracle University 公開試験ガイドを一次根拠として検証し、独自のSVG視覚図解として作成しています。
- Load Balancer Concepts
- Load Balancer Management
- Creating a Load Balancer
- Creating a Load Balancer Listener
- Health Check Policies for Load Balancers
- Rule Sets for Load Balancers
- Overview of Certificates
- Renewing a Certificate
- Overview of Web Application Firewall
- Adding a Firewall to a Web Application Firewall Policy
- Understanding Conditions
- IAM Identity Domain Types
- Adding a Confidential Application
- Creating a Sign-On Policy
- Managing Network Perimeters
- Understanding App Gateway
- Always Free Resources
LBの後ろにComputeを置く
ロードバランサーは Flexible Load Balancer を使います。外から受けるので、公開のLBを public-lb(10.0.0.0/24)に置きます。公開のLBはプライベートサブネットに置けません。ADが1つの東京リージョンでは、1つのパブリックサブネットにプライマリとスタンバイが置かれ、プライベートIPを2つ使います。
3つの部品を覚えると、設定画面が読みやすくなります。
表1:LBの部品と今回の設定
- 接続:社員のブラウザがDNSで引いた公開IPへ、HTTPSでつなぎます。
- TLS終端:リスナーが証明書を使って暗号を解きます。
- WAF判定:ポリシーのルールで、通すか止めるかを決めます。
- 振り分け:正常なバックエンドへ、ポート8080で渡します。
- ヘルスチェック:LBが2台へ定期的に確かめ、失敗した台を外します。
作成の手順
LBの作成画面は5段階です。証明書は3の Configure listener で指定するので、先に用意しておきます。
- Add details:Public を選び、Public IP address は Reserved IP address にする。Flexible shapes で帯域を決め、VCNと
public-lbを指定する。Use network security groups to control traffic を有効にしてnsg-lbを付ける。 - Choose backends:Compute 2台を追加し、Health check policy を設定する。セキュリティのルールは手動を選び、NSGで書く。
- Configure listener:この時点では、次の節で用意する証明書を指定する。
- Manage logging:Error logs と Access logs を有効にする。
- Review and create:内容を見て作成する。
Health check policy の既定は、間隔10秒、タイムアウト3秒、再試行3回です。帯域は10〜8,000 Mbpsの範囲で指定します。Always Free の対象テナンシには、10 Mbps固定の Flexible Load Balancer が1つ含まれます(2026-11-01確認。最新は公式で確認してください)。
NSGのルール
ステートフルなルールで次の表を作ります。公式は大量の通信にはステートレスなルールを勧めていますが、社員30人のアプリなら、読みやすいステートフルで始めて問題になりにくいでしょう。
表2:LBとアプリのNSGルール
HTTPSにする
HTTPSには、ドメインと証明書が要ります。ここでは社内用のサブドメインを keihi.example.net とします。
- 作成時に指定した Reserved IP address を確かめる。LBを作り直してもIPを残せるので、DNSを変えずに済む。
- DNSに、
keihi.example.netからLBの公開IPへのAレコードを作る。 - 証明書を用意し、HTTPSリスナーに設定する。
リスナーの Certificate resource は2種類あります。Load balancer managed certificate はPEMを直接読み込みます。Certificate service managed certificate は OCI Certificates の証明書を選びます。外部の証明書をインポートした場合は自動更新の対象外です。
表3:証明書の入手方法
| 入手方法 | 信頼のされ方 | 更新 |
|---|---|---|
| 公開CAの証明書をインポート | ブラウザが信頼するCAなら、端末の設定は要らない | 自動更新の対象外。新しいPEMを手で入れる |
| OCI Certificates の内部CAで発行 | 端末がそのルートCAを信頼する必要がある | 自動更新のルールを設定できる |
LBからバックエンドまでの暗号化
LBでTLSを終端すると、LBからComputeまでは暗号化されない通信になります。バックエンドセットにSSLを設定すれば、LBからComputeへの通信も暗号化できます(公式は point-to-point SSL と呼びます)。この場合、LBとバックエンドの間のmTLSには対応していません。ヘルスチェックのプロトコルとの整合も確かめてください。
80番のリダイレクトは任意
今回は、外から届くのを443だけにしたいので、80番を開けません。利用者にはHTTPSのURLを案内します。必要なら、HTTPリスナーにルールセットのURLリダイレクトを設定できます。プロトコルをHTTPS、ポートを443、応答コードを301にします。入力しない項目は受信時の値が残るので、ループやポートの誤りに注意します。80番を開ける分、NSGのルールも増えます。
WAFを付ける
OCIのWAFには2つの形があります。WAF policy はLBに付けるリージョナルの方式で、Edge policy はDNSを Oracle の CNAME に向ける従来型のグローバルの方式です。今回は東京の社員向けなので、リージョナルのWAFポリシーを選びます。
ポリシーは3つのモジュールで考えます。
表4:WAFポリシーの主な部品と今回の使い方
| 部品 | 役割 | 今回の使い方 |
|---|---|---|
| Access Control | リクエストの属性を見て、応答を決める | 想定しない国からの接続を止める |
| Rate Limiting | キーごとにリクエストの頻度を制限する | 同じ接続元からの連続した要求を抑える |
| Protection Rules | 悪意のある内容を検査する | 領収書のアップロードで誤検知がないか見ながら使う |
ポリシーをLBへつなぐには、Firewall というリソースを作ります。公式はこれを、ポリシーと適用先をつなぐ論理的なリンクと説明しています。
- WAFのポリシーを作り、ルールの動作は Check(記録のみ)から始める。
- ポリシーの Firewalls から Add firewalls を選び、対象のLBを指定する。
- セキュリティ・ログを有効にする。公式も有効にすることを勧めています。
- 誤検知がないことを確かめて、Return HTTP response(止める動作)へ切り替える。
CLIなら次のコマンドです。
oci waf web-app-firewall create-for-load-balancer \
--compartment-id <コンパートメントのOCID> \
--load-balancer-id <LBのOCID> \
--web-app-firewall-policy-id <WAFポリシーのOCID>
公式のWAFの資料は前提をHTTPリスナーと書き、TCPリスナーは非対応としています。HTTPSと明記した記述はありませんが、SSLリスナーのLBへWAFを付ける公式手順があります。HTTP/2 などを使うときは、設定後に動作を確かめてください。料金はインスタンスとリクエスト数で変わるので、公式の価格表で確かめてください。
アプリのログインを守る
ここからは「社員だけが使う」ための話です。役割を分けて考えると、設計が整理できます。
表5:社員だけが使うための層
| 層 | 手段 | 確かめること | 外出先での限界 |
|---|---|---|---|
| ネットワーク | NSG、WAFのIP条件 | 接続元のIP | 移動先のIPは事前に分からない |
| 国 | WAFの国コード条件 | 接続元の国 | 海外出張があるなら例外が要る |
| 利用者 | Identity Domains のサインインとMFA | 本人かどうか | IPが変わっても使える |
WAFで国を絞る
Access Control の条件はJMESPathで書きます。日本以外からの接続を止めるなら、次の条件のルールに Return HTTP response を組み合わせます。国が判定できないと値が null になるので、これも一致します。正規の社員が止まらないか、Check で確かめてから有効にしましょう。
!contains(['JP'], connection.source.geo.countryCode)
固定の出口があるなら、address_in(connection.source.address, ['203.0.113.0/24']) のようにIPでも条件を書けます。
Identity Domains でサインインする
カスタムのアプリでは、IAM Identity Domains の Confidential Application を使い、アプリにOIDCを実装する方法が基本です。LBの作成手順には、ログインの設定項目は見当たりません。認証はアプリ側で行います。
- アクセス:ブラウザがアプリのURLを開きます。
- リダイレクト:未ログインなら、アプリがサインイン画面へ移します。
- サインイン:IDとパスワードに加え、サインオン・ポリシーがMFAを求めます。
- 認可コード:登録したRedirect URLへ、コードを持って戻ります。
- コードを渡す:ブラウザが同じ経路でアプリへコードを届けます。
- トークン交換:アプリがクライアントIDとシークレットでトークンに換えます。
設定の手順は次のとおりです。
- ドメインの Integrated applications で Add application を選び、Confidential Application を選ぶ。Enforce grants as authorization を選ぶ。外すと、認証済みの利用者なら誰でも使えます。
- Configure OAuth で Authorization code を選び、Redirect URL に
https://keihi.example.net/callbackのような絶対URLを入れる。Allow HTTP URLs は使わない。 - 表示された Client ID と Client secret を記録する。シークレットは Vault に置く。
- アプリを Activate し、社員のグループを Groups で割り当てる。
- サインオン・ポリシーを作り、Prompt for an additional factor でMFAを求める。Applications タブからアプリを追加して、ポリシーを有効にする。
ドメインの種類と App Gateway
ドメインの種類で使える範囲が変わります。Free でもカスタムアプリのSSOとサインオン・ポリシーは使えますが、Oracle以外のアプリは自社開発のものも含めて2つまでで、SMSのMFAは含まれません(2026-11-01確認)。使うドメインの種類を確かめてください。
アプリにOIDCを組み込めない場合は、App Gateway という選択肢があります。アプリの前に置くリバースプロキシで、サインインを確かめてからリクエストを渡します。Premium か External User のドメインが必要で、ヘッダーで利用者を伝えるので、App Gateway とアプリの間の通信を守る必要があります。
サインオン・ポリシーでは、Network perimeter で接続元を条件にできます。ただし、これが効くのはサインインの場面です。外出先で使うなら、IPより先にMFAを必須にしましょう。
次に読むページ
ロードマップの次の項目は「使い始める前に通信を点検する」です。VCNとNSGの記事を見ながら、外から届くのがLBの443だけかを確かめましょう。全体の順番は学習ロードマップで確認できます。
よくある質問(FAQ)
- WAFを付ければ、アプリのログイン機能は要りませんか?
- 必要です。WAFは通信の内容や接続元でリクエストを判定しますが、利用者が社員かどうかを確かめるものではありません。社員だけが使うには、IAM Identity Domains などでサインインを行い、アプリで認証を確認します。
- 社内向けなら、プライベートのロードバランサーにできませんか?
- 社員が必ず閉域の経路で入れるなら候補です。今回の題材は外出先からインターネット経由で使う前提なので、公開のロードバランサーを public-lb に置きます。公開のロードバランサーはプライベートサブネットには置けません。
- OCIの証明書サービスの内部CAで、公開用のHTTPS証明書を作れますか?
- OCI Certificates では内部のCAを作って証明書を発行できますが、証明書が信頼されるには、検証する側がそのルートCAを信頼している必要があります。社員の端末にルート証明書を配らないなら、ブラウザが信頼するCAの証明書をインポートする方法が分かりやすいでしょう。