OCIのロードバランサーにHTTPSとWAFを付け、社内アプリを外出先から安全に使う

※当ページにはAmazonアソシエイト等の広告リンクを含みます。

公式ドキュメントで検証最終検証 2026-11-01編集部出典 17件

LBの後ろにComputeを置く

ロードバランサーは Flexible Load Balancer を使います。外から受けるので、公開のLBを public-lb(10.0.0.0/24)に置きます。公開のLBはプライベートサブネットに置けません。ADが1つの東京リージョンでは、1つのパブリックサブネットにプライマリとスタンバイが置かれ、プライベートIPを2つ使います。

3つの部品を覚えると、設定画面が読みやすくなります。

表1:LBの部品と今回の設定

部品役割今回の設定
リスナーLBのIPに届く通信を、プロトコルとポートで受けるHTTPS、443
バックエンドセットバックエンド、分散の方法、ヘルスチェックの組み合わせCompute 2台の 8080、Weighted round robin
ヘルスチェック定期的に確かめ、失敗した台を一時的に外すHTTP、8080、/healthz、200
Request Path社員のリクエストがアプリへ届くまで
DNSAレコード社員外出先不審な通信VCN 10.0.0.0/16public-lbFlexible LB(予約済みの公開IP)リスナーHTTPS 443WAFポリシー通す・止めるバックエンドセットprivate-appCompute 1FD 1 / 8080Compute 2FD 2 / 8080GET /healthzここから先へ通さない12345
  1. 接続:社員のブラウザがDNSで引いた公開IPへ、HTTPSでつなぎます。
  2. TLS終端:リスナーが証明書を使って暗号を解きます。
  3. WAF判定:ポリシーのルールで、通すか止めるかを決めます。
  4. 振り分け:正常なバックエンドへ、ポート8080で渡します。
  5. ヘルスチェック:LBが2台へ定期的に確かめ、失敗した台を外します。
図1:入口はLBの443だけで、Compute 2台に公開IPはない。処理の順序を概念として示している

作成の手順

LBの作成画面は5段階です。証明書は3の Configure listener で指定するので、先に用意しておきます。

  1. Add details:Public を選び、Public IP address は Reserved IP address にする。Flexible shapes で帯域を決め、VCNと public-lb を指定する。Use network security groups to control traffic を有効にして nsg-lb を付ける。
  2. Choose backends:Compute 2台を追加し、Health check policy を設定する。セキュリティのルールは手動を選び、NSGで書く。
  3. Configure listener:この時点では、次の節で用意する証明書を指定する。
  4. Manage logging:Error logs と Access logs を有効にする。
  5. 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ルール

NSG方向相手ポート理由
nsg-lb受信0.0.0.0/0TCP 443外出先のIPは固定できないため。出口が固定できるなら、そのCIDRに絞る
nsg-lb送信nsg-appTCP 8080アプリとヘルスチェックの通信
nsg-app受信nsg-lbTCP 8080LBからの通信だけを受ける

HTTPSにする

HTTPSには、ドメインと証明書が要ります。ここでは社内用のサブドメインを keihi.example.net とします。

  1. 作成時に指定した Reserved IP address を確かめる。LBを作り直してもIPを残せるので、DNSを変えずに済む。
  2. DNSに、keihi.example.net からLBの公開IPへのAレコードを作る。
  3. 証明書を用意し、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 というリソースを作ります。公式はこれを、ポリシーと適用先をつなぐ論理的なリンクと説明しています。

  1. WAFのポリシーを作り、ルールの動作は Check(記録のみ)から始める。
  2. ポリシーの Firewalls から Add firewalls を選び、対象のLBを指定する。
  3. セキュリティ・ログを有効にする。公式も有効にすることを勧めています。
  4. 誤検知がないことを確かめて、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の作成手順には、ログインの設定項目は見当たりません。認証はアプリ側で行います。

OIDC Sign-in社員がサインインしてアプリへ戻るまで
社員のブラウザ外出先public-lbLB+WAFHTTPS 443private-app経費申請アプリOIDCを実装アイデンティティ・ドメインサインオン・ポリシーとMFA123456
  1. アクセス:ブラウザがアプリのURLを開きます。
  2. リダイレクト:未ログインなら、アプリがサインイン画面へ移します。
  3. サインイン:IDとパスワードに加え、サインオン・ポリシーがMFAを求めます。
  4. 認可コード:登録したRedirect URLへ、コードを持って戻ります。
  5. コードを渡す:ブラウザが同じ経路でアプリへコードを届けます。
  6. トークン交換:アプリがクライアントIDとシークレットでトークンに換えます。
図2:認可コードの流れ。サインインとMFAはアイデンティティ・ドメインで行う

設定の手順は次のとおりです。

  1. ドメインの Integrated applications で Add application を選び、Confidential Application を選ぶ。Enforce grants as authorization を選ぶ。外すと、認証済みの利用者なら誰でも使えます。
  2. Configure OAuth で Authorization code を選び、Redirect URL に https://keihi.example.net/callback のような絶対URLを入れる。Allow HTTP URLs は使わない。
  3. 表示された Client ID と Client secret を記録する。シークレットは Vault に置く。
  4. アプリを Activate し、社員のグループを Groups で割り当てる。
  5. サインオン・ポリシーを作り、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の証明書をインポートする方法が分かりやすいでしょう。
目次