技術記事・調査 2025/04/15

OneGateから発行した証明書を使ってAWS ALBをセキュアにする-その1「SSLオフロード」

最近クラウドの利用がますます増えて、オンプレシステムをAWSやAzureなどのクラウドに移行するケースが増えています。
オンプレのWebアプリケーションをAWSに移行する際に、Webサーバーといっしょにロードバランサーも移行することも検討されると思いますが、AWSのマーケットプレイスに利用しているロードバランサーがあるとも限りません。また昨今ではAWSの機能を利用してシステムを組み直すこともできます。
AWSにはApplication Load Balancer(以下、ALB)があり、オンプレで利用していたロードバランサーの代わりにALBを利用することができます。

このALBにはロードバランサーとして動作するのはもちろん、HTTPSで受信したものを復号してバックエンド (ターゲット)のWebサーバーにHTTPとしてデータを渡すことができるSSLオフロードの機能があり、Webサーバーで復号処理が不要となりWebサーバー自体の負荷を軽減させることが可能です。

そこで、Soliton OneGate(以下、OneGate)から発行したサーバー証明書を利用してALBでSSLオフロードを実現する方法を紹介します。

構成

ALBを利用するには、VPCにそれぞれ異なるアベイラビリティゾーンのサブネットが2つ以上必要になります。それぞれのアベイラビリティゾーンのサブネットにAmazon Linux 2023でWebサーバーを構築して、これをALBでHTTPS化するようにします。

通常であればWebサーバーはメンテナンス用の作業用マシンを作成し、そのマシンからのみSSH接続を許可する構成を取ることが多いと思いますが、今回は割愛させていただき、社内(宅内)ネットワークから直接SSH接続する構成にしております。

構築の流れ

今回は新規でVPCの作成から行い、最終的にALBでロードバランシングしつつ、SSLオフロードする方法を紹介します。

大まかな流れは次の通りです。

VPCの作成
インターネットゲートウェイの作成
サブネットの作成
Webサーバー用のセキュリティグループを作成して、社内からSSH及びHTTPでアクセスできるようにする
Amazon Linux 2023でWebサーバー構築して、社内からHTTPアクセスできることを確認
ALB用のネットワークセキュリティグループを作成して、ALBに対してHTTPでアクセスできるようにする
ALBを構築して社内からHTTPでALB経由でWebサーバーにアクセスできるようにする
ALBに割りあった名前を使ってOneGateでサーバー証明書を作成してALB適用してSSLオフロードする

なお、新規でVPCやインターネットゲートウェイ、サブネット、EC2インスタンスを作成しておりますが、既にVPCや異なるアベイラビリティゾーンのサブネットが2つ以上ある場合はそちらを利用していただいても問題ございません。

ターゲットとなるWebサーバーの構築

今回利用しているAWS上に色々と検証環境があり、それらと区別するために名前タグの命名規則を「NetAtest-<リソース名>」としています。実際に構築する場合には、自社内のAWS利用規則に従って命名規則やVPCのIPアドレスレンジなどを設定してください。

VPCの作成

VPCダッシュボードにて「仮想プライベートクラウド」→「お使いのVPC」を開き、「VPCの作成」をクリックします。

下記の様に設定して「VPCを作成」をクリックします。

項目	値
作成するリソース	VPCのみ
名前タグ-オプション	NetAttest-vpc
IPv4 CIDRブロック	IPv4 CIDRの手動入力
IPv4 CIDR	適当なアドレス範囲例)192.168.0.0/16
IPv6 CIDRブロック	IPv6 CIDRブロックなし

VPCが作成されたら「アクション」→「VPCの設定を編集」をクリックします。
「DNSホスト名を有効化」にチェックをいれて「保存」をクリックします。

インターネットゲートウェイの作成

既にインターネットゲートウェイがある場合には、作成せずにそちらをご利用になられても問題ございません。

VPCダッシュボードで「仮想プライベートクラウド」→「インターネットゲートウェイ」を開いて「インターネットゲートウェイの作成」をクリックします。
名前タグ欄に「NetAttest-ig」を入力して「インターネットゲートウェイの作成」をクリックします。
「アクション」→「VPCにアタッチ」をクリックします。
「使用可能なVPC」で作成したNetAttest-vpcを選択して「インターネットゲートウェイのアタッチ」をクリックします。

サブネットの作成

先に説明した通り、ALBを利用するにはアベイラビリティゾーンが異なるサブネットが2つ以上必要になります。今回は東京リージョンのap-northeast-1aとap-northeast-1cの2つのアベイラビリティゾーンに所属するサブネットを作成します。

こちらに関しても既にVPCに異なるアベイラビリティゾーンのサブネットがあれば新規に作成しないでも大丈夫です。

VPCダッシュボードにて「仮想プライベートクラウド」→「サブネット」を開き「サブネットを作成」をクリックします。

下記を設定して「新しいサブネットを追加」をクリックします。

項目	値
VPC ID	作成したVPC 例)NetAttest-vpc
サブネット名	ap-northeast-1a所属がわかるような名前例)NetAttest-1a-sub
アベイラビリティゾーン	アジアパシフィック(東京)/ap-northeast-1a
IPv4 VPC CIDRブロック	NetAttest-vpcのCIDRブロック例)192.168.0.0/16
IPv4サブネット CIDRブロック	適当なサブネット例)192.168.1.0/24

サブネット2(2個中)が表示されますので、下記を設定して「サブネットを作成」をクリックします。

項目	値
サブネット名	ap-northeast-1c所属がわかるような名前例)NetAttest-1c-sub
アベイラビリティゾーン	アジアパシフィック(東京)/ap-northeast-1c
IPv4 VPC CIDRブロック	NetAttest-vpcのCIDRブロック
IPv4 サブネットCIDRブロック	192.168.2.0/24

ルートテーブルの作成

サブネットからインターネットに出れるようにルートテーブルを作成します。
こちらについても既に作成済みのサブネットに紐づいているルートテーブルがあれば新規に作成しなくても大丈夫です。

VPCダッシュボードから「仮想プライベートクラウド」→「ルートテーブル」を開いて「ルートテーブルを作成」をクリックします。
下記を設定して「ルートテーブルを作成」をクリックします。
項目値
名前 NetAttest-rt
VPC 作成済みのVPC
例)NetAttest-vpc
「アクション」→「サブネットの関連付けを編集」をクリックします。
作成したNetAttest-1a-subとNetAttest-1c-subを選択して「関連付けを保存」をクリックします。
続いてインターネットへのアクセスルートを設定します。「アクション」→ 「ルートを編集」をクリックします。
「ルートを追加」をクリックします。
下記を設定して「変更を保存」をクリックします。
項目値
送信先 0.0.0.0/0
ターゲットインターネットゲートウェイ
NetAttest-ig

セキュリティグループの作成

これから構築するWebサーバーに対して社内からのみSSHとHTTPアクセスを許可するセキュリティグループを作成します。

VPCダッシュボードにて「セキュリティ」→「セキュリティグループ」を開き「セキュリティグループを作成」をクリックします
下記を設定して「セキュリティグループを作成」をクリックします。
- 基本的な詳細
  項目値
  セキュリティグループ名 NetAttest-WebSrv-nsg
  情報適当な値
  VPC NetAttest-vpc
- インバウンドルール
  タイプソース
  SSH マイIP
  HTTP マイIP
- アウトバウンドルール
  タイプ送信先
  すべてのトラフィックカスタム
  0.0.0.0/0

Amazon Linux 2023へSSH接続用のキーペアを作成

WebサーバーにSSH接続する際のキーペアを作成します。既存で作成済みのキーペアを利用する場合には、この操作は不要です。

EC2ダッシュボードにて「ネットワーク＆セキュリティ」→「キーペア」を開き「キーペアを作成」をクリックします。

下記を設定して「キーペアを作成」をクリックします。

項目	値
名前	NetAttest-Key
キーペアのタイプ	ED25519
プライベートキーファイル形式	SSH接続にTeraTermを利用する場合には「.pem」を選択

ローカルに保存します。

Amazon Linux 2023でWebサーバーを構築

Amazon Linux 2023を使ってWebサーバーを構築します。Webサーバーはnginxを使用します。

NetAttet-1a-subサブネットで稼働するWebサーバー

EC2ダッシュボードにて「インスタンス」→「インスタンス」を開き「インスタンスを起動」をクリックします。

下記を設定して「インスタンスを起動」をクリックします。

名前とタグ
項目値
名前 NetAttet-1a-web
アプリケーションおよびOSイメージ(Amazonマシンイメージ)
項目値
Amazonマシンイメージ(AMI) Amazon Linux 2023 AMI
アーキテクチャ 64ビット(x86)
インスタンスタイプ
項目値
インスタンスタイプ t2.micro
キーペア
項目値
キーペア名 NetAttest-key

ネットワーク設定
「編集」をクリックしてから下記を設定してください。

項目	値
VPC	NetAttest-vpc
サブネット	NetAttest-1a-sub
パブリックIPの自動割り当て	有効化 ※Webサーバー構築後に「無効化」にします
ファイアウォール(セキュリティグループ)	既存のセキュリティグループを選択する
共通のセキュリティグループ	NetAttest-WebSrv-nsg

ストレージ
デフォルト値で大丈夫です。

EC2ダッシュボードにて「インスタンス」→「インスタンス」にて作成したNetAttest-1a-webを選択して、ステータスチェックが「2/2のチェックに合格しました」と表示され、パブリックIPv4アドレスが表示されるのを待ちます。
表示されたパブリックIPv4アドレスTeraTermなどでSSH接続します。
- ホストの欄にパブリックIPv4アドレスを入力して「OK」をクリックします。
- 初めて接続するときはセキュリティ警告が表示されますので、「このホストをknow hostsリストに追加する」にチェックをいれて「続行」をクリックします。
- 下記を入力して「OK」をクリックします。
  項目値
  ユーザー名 ec2-user
  認証方式 RSA/DSA/ECDSA/ED25519鍵を使う
  秘密鍵作成した秘密鍵
- 下記のように表示されればSSH接続完了です。以後はこのコンソールを使用してWebサーバーを構築します。
タイムゾーンがUTCになっていますので、気になる方は下記を入力してJSTにしてください。(任意です)
```
 $ sudo timedatectl set-timezone Asia/Tokyo
```

WebサーバーとしてNginxをインストールして自動起動するようにします。

$ sudo dnf -y install nginx
$ sudo systemctl start nginx
$ sudo systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
$ systemctl is-enabled nginx
enabled

このままブラウザで「http://<パブリックIPv4アドレス>」にアクセスするとNginxのデフォルトページが表示されますが、今回Webサーバーを2つ建ててALBでロードバランシングを行うため、どちらのWebサーバーにアクセスしているかをわかりやすくするために、デフォルトページを変更します。

$ sudo rm -r /usr/share/nginx/html/index.html
$ sudo vi /usr/share/nginx/html/index.html

<html>
    <head>
        <meta charset="UTF-8">
        <style type="text/css">
            body {background-color: green}
            h1,p {color: white}
        </style>
        <title>Webサーバー1へようこそ</title>
    </head>
    <body>
        <h1>Webサーバー1へようこそ</h1>
        <p>このサーバーはap-northeast-1aで動作しています。</p>
    </body>
</html>

ブラウザでアクセスして確認します。 ※アクセスできない場合には、EC2ダッシュボードにてインスタンスを開いてセキュリティタブに表示されているインバウンドルールが間違っていないかを確認してください。

NetAttest-1c-subサブネットで稼働するWebサーバー

NetAttest-1a-subに構築したWebサーバーと同等のものをNetAttest-1c-subに構築します。

EC2ダッシュボードにて「インスタンス」→「インスタンス」を開き「インスタンスを起動」をクリックします。

下記を設定して「インスタンスを起動」をクリックします。

名前とタグ
項目値
名前 NetAttet-1c-web
アプリケーションおよびOSイメージ(Amazonマシンイメージ)
項目値
Amazonマシンイメージ(AMI) Amazon Linux 2023 AMI
アーキテクチャ 64ビット(x86)
インスタンスタイプ
項目値
インスタンスタイプ t2.micro
キーペア
項目値
キーペア名 NetAttest-key

ネットワーク設定「編集」をクリックしてから下記を設定してください。

項目	値
VPC	NetAttest-vpc
サブネット	NetAttest-1c-sub
パブリックIPの自動割り当て	有効化 ※Webサーバー構築後に「無効化」にします
ファイアウォール(セキュリティグループ)	既存のセキュリティグループを選択する
共通のセキュリティグループ	NetAttest-WebSrv-nsg

ストレージ
デフォルト値で大丈夫です。

EC2ダッシュボードにて「インスタンス」→「インスタンス」にて作成したNetAttest-1c-webを選択して、ステータスチェックが「2/2のチェックに合格しました」と表示され、パブリックIPv4アドレスが表示されるのを待ちます。
表示されたパブリックIPv4アドレスTeraTermなどでSSH接続します。
- ホストの欄にパブリックIPv4アドレスを入力して「OK」をクリックします。
- 初めて接続するときはセキュリティ警告が表示されますので、「このホストをknow hostsリストに追加する」にチェックをいれて「続行」をクリックします。
- 下記を入力して「OK」をクリックします。
  項目値
  ユーザー名 ec2-user
  認証方式 RSA/DSA/ECDSA/ED25519鍵を使う
  秘密鍵作成した秘密鍵
- 下記のように表示されればSSH接続完了です。以後はこのコンソールを使用してWebサーバーを構築します。
タイムゾーンがUTCになっていますので、気になる方は下記を入力してJSTにしてください。(任意です)
```
 $ sudo timedatectl set-timezone Asia/Tokyo
```

WebサーバーとしてNginxをインストールして自動起動するようにします。


$ sudo dnf -y install nginx
$ sudo systemctl start nginx
$ sudo systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
$ systemctl is-enabled nginx
enabled

NetAttest-1a-Webと同様にデフォルトページを変更します。

$ sudo rm -r /usr/share/nginx/html/index.html
$ sudo vi /usr/share/nginx/html/index.html

<html>
    <head>
        <meta charset="UTF-8">
        <style type="text/css">
            body {background-color: blue;}
            h1,p {color: white}
        </style>
        <title>Webサーバー2へようこそ</title>
    </head>
    <body>
        <h1>Webサーバー2へようこそ</h1>
        <p>このサーバーはap-northeast-1cで動作しています。</p>
    </body>
</html>

ブラウザでアクセスして確認します。 ※アクセスできない場合には、EC2ダッシュボードにてインスタンスを開いてセキュリティタブに表示されているインバウンドルールが間違っていないかを確認してください。

Webサーバーに対してALBでロードバランシングさせる

構築した2つのWebサーバーへのHTTPアクセスをALBでロードバランシングさせます。

ALB用のセキュリティグループの作成

ALB経由でWebサーバーにHTTP及びHTTPSでアクセスできるように、ALBに対してHTTPとHTTPS通信を許可するセキュリティグループを作成します。

VPCダッシュボードにて「セキュリティ」→「セキュリティグループ」を開「セキュリティグループを作成」をクリックします。
下記のように設定して「セキュリティグループを作成」をクリックします。
- 基本的な詳細
  項目値
  セキュリティグループ名 Netattest-alb-nsg
  説明任意
  VPC NetAttest-vpc
- インバウンドルール
  タイプソース
  HTTP マイIP
  HTTPS マイIP
  ,
- アウトバウンドルール
  タイプソース
  すべてのトラフィックカスタム
  0.0.0.0/0

ALBからWebサーバーにアクセスを許可する

Webサーバー用のセキュリティグループでは社内のIPからHTTPで通信ができるようになっていますが、これを廃止してALBのセキュリティグループからHTTPの通信ができるようにします。

VPCダッシュボードの「セキュリティ」→「セキュリティグループ」にてWebサーバー用のセキュリティグループであるNetAttest-WebSrv-nsgを開き、「インバウンドルールの編集」をクリックします。
HTTPのルールを削除します。
下記のように設定して「ルールを保存」をクリックします。
タイプソース
SSH マイIP
HTTP カスタム
セキュリティグループ
NetAttest-alb-nsg
HTTPS カスタム
セキュリティグループ
NetAttest-alb-nsg

ターゲットグループの作成

ALBでの振り分け先を設定します。

EC2ダッシュボードにて「ロードバランシング」→「ターゲットグループ」を開き「ターゲットグループの作成」をクリックします。

下記のように設定して「次へ」をクリックします。

基本的な設定

項目	値
ターゲットタイプの選択	インスタンス
ターゲットグループ	NetAttest-Web-target
プロトコル：ポート	HTTP:80
IPアドレスタイプ	IPv4
VPC	NetAttest-vpc
プロトコルバージョン	HTTP1

ヘルスチェック
項目値
ヘルスチェック HTTP
ヘルスチェックパス /

使用可能なインスタンスにてNetAttest-1a-webインスタンスとNetAttest-1c-webインスタンスにチェックををいれて「保留中として以下を含める」をクリックします。
選択した2つのインスタンスがターゲットに含まれていること確認して「ターゲットグループの作成」をクリックします。

ALBの作成

EC2ダッシュボードにて「ロードバランシング」→「ロードバランサー」を開いて「ロードバランサーの作成」をクリックします。
ロードバンサータイプにてApplication　Load Balancerの「作成」をクリックします。
下記を設定して「ロードバランサーの作成」をクリックします。
- 基本的な設定
  項目値
  ロードバランサー名 NetAttest-alb
  スキームインターネット向け
  ロードバランサーのIPアドレスタイプ IPv4
- ネットワークマッピング
  項目値
  VPC NetAttest-vpc
  アベイラビリティゾーンとサブネット ap-northeast-1a(apone1-az4)/NetAttest-1a-sub
  ap-northeast-1c(apone1-az1)/NetAttest-1c-sbu
- セキュリティグループ
  項目値
  セキュリティグループ NetAttest-alb-nsg
- リスナーとルーティング
  項目値
  プロトコル HTTP
  ポート 80
  デフォルトアクション NetAttest-Web-target
数分待つとステータス欄が「アクティブ」になりALBが稼働しますので、DNS名欄の値をコピーします。
ブラウザのURL欄に「http://DNS名の値」を入力して、アクセスできることを確認します。
ブラウザを何度かリロードするとサーバーが切り替わり、ロードバランシングしていることがわかります。

ALBにHTTPSアクセスしてSSLオフロードさせる

ALBでHTTPのロードバランシングができましたので、これをHTTPS化します。
HTTPS化するには通常であればWebサーバーであるNginx側でSSL有効の設定をするのですが、今回はWebサーバー側はHTTPのままで、ALBでHTTPSをHTTP化して転送するようにします。

サーバー証明書の発行

OneGateからロードバランサーに対してサーバー証明書を発行します。

今回はサーバー証明書のCNとサブジェクト代替名(SANs)のDNS名については、ALBのDNS名を記載するようにしますが、通常の運用ではALBへのアクセスをAWSが自動生成したDNS名ではなくて、自社のDNSサーバーでCNAMEで別名を割り当て、そのCNAMEの値でアクセスすると思いますので、その際にはCNとSANsのDNS名についてはCNAMEの値で発行してください。NetAttest D3でドメイン管理している場合のCNAMEの例
この場合はCN及びSANsのDNS名は「webapp.example.com」になる

EC2ダッシュボードにて「ロードバランシング」→「ロードバンサー」にて作成したNetAttest-albを開いてDNS名の値を控えます。
OneGateの管理者ページにて「証明書管理」→「証明書発行」をクリックします。
「サーバー証明書発行」欄の「PKCS#12ファイルまたは秘密鍵＋証明書 PEM形式のサーバー証明書を発行をクリックします。

下記のように入力して「発行」をクリックして、証明書ファイルを保存します。なお、OneGateで発行したサーバー証明書は秘密鍵がパスフレーズによって保護(暗号化)されいるため、そのままではAWSに取り込めませんので、秘密鍵による保護を解除する必要があります。

項目	値
名前(CN)	ALBのDNS名(※)
国(C)	日本
都道府県名(S)	任意
市区町村名(L)	任意
組織名(O)	任意
部署名(OU)	任意
Emailアドレス	空欄
DNS名	ALBのDNS名(※)
鍵長	4096
拡張キー使用方法	TLS Webサーバー認証(1.3.6.1.5.5.7.3.1)
証明書の有効期限	任意
ダウンロードファイル形式	PEM形式(秘密鍵＋サーバー証明書)
パスフレーズ	任意の文字列

※OneGateからサーバー証明書を発行する場合、CN及びSANsのDNS名は64文字以下にする必要があります。ALBのリソース名を長い文字列にすると生成されるDNS名が64文字以上になるとこともありますが、その場合にはOneGateでサーバー証明書が発行できなくなります。文字数に引っかかってサーバー証明書が発行できない場合にはCNとSANsのDNS名を「*.ap-northeast-1.elb.amazonaws.com」などワイルドカードを使用した値にしてください。

ダウンロードした証明書ファイルをメモ帳で開いておきます。
秘密鍵の保護を解除するため、OpenSSLが使える環境(WebサーバーになっているAmazon Linux 2023でも代用可)で、メモ帳で開いている証明書ファイルの「-----BEGIN ENCRYPTED PRIVATE KEY-----」から「-----END ENCRYPTED PRIVATE KEY-----」が記載されたsrv-enc.keyファイルを作成します。$vi srv-enc.key -----BEGIN ENCRYPTED PRIVATE KEY----- MIIJmjBMBgkqhkiG9w0BBQ0wPzAnBgkqhkiG9w0BBQwwGgQUVtfcNKOXgr334nGb ＜中略＞ kE5GnzNJ92yTuhJfsF4= -----END ENCRYPTED PRIVATE KEY-----
OpenSSLコマンドを使って秘密鍵の保護を解除したsrv.keyファイルを生成します。$ openssl rsa -in srv-enc.key -out srv.key Enter pass phrase for srv-enc.key:＜サーバー証明書を発行したときのパスフレーズ＞ writing RSA key
catコマンド等でsrv.keyファイルを開いておきます。$ cat srv.key -----BEGIN PRIVATE KEY----- MIIJQgIBADANBgkqhkiG9w0BAQEFAASCCSwwggkoAgEAAoICAQCoUYcyFGm5ml5g ＜中略＞ il698UAW116MV//ggiWpzRMvNMfUUg== -----END PRIVATE KEY-----

ACMにサーバー証明書を保存

AWSにて「AWS Certificate Manager(ACM)」を開き、「証明書をインポート」をクリックします。
「証明書本文」欄にメモ帳で開いている証明書ファイルの「-----BEGIN CERTIFICATE-----」から「-----END CERTIFICATE-----」の値を入力し、「証明書のプライベートキー」欄には秘密鍵保護を解除したsrv.keyの「-----BEGIN PRIVATE KEY-----」から「-----END PRIVATE KEY-----」の値を貼り付けて、「証明書をインポート」をクリックします。
作業で使用したsrv.keyファイルは秘密鍵保護がされておりませんので、必ず削除してください。(必要に応じてsrv-enc.keyファイルも削除してください。)$ rm srv.key $ rm srv-enc.key

HTTPSリスナーの追加

ALBにHTTPSを受信するリスナーを追加し、OneGateで発行したサーバー証明書を使ってHTTPS通信できるようにします。

EC2ダッシュボードにて「ロードバランシング」→「ロードバンサー」にて作成したNetAttest-albを開いて「リスナーとルール」タブの「リスナーの追加」をクリックします。
下記を設定して「追加」をクリックします。
- リスナーの設定
  項目
  値
  プロトコル
  HTTPS
  ポート
  443
- デフォルトアクション
  項目
  値
  アクションのルーティング
  ターゲットグループへ転送
  ターゲットグループ
  NetAttest-Web-target
  重み
  1
- セキュリティポリシー
  項目
  値
  セキュリティカテゴリ
  すべてのセキュリティポリシー
  ポリシー名
  任意
  例)ELBSecurityPolicy-TLS13-2-2021-6
- デフォルトSSL/TLSサーバー証明書
  項目
  値
  証明書の取得先
  ACMから
  証明書
  ACMにアップロードしたサーバー証明書
ブラウザで「https://<ALBのDNS名>」にアクセスして、HTTPS通信でWebサーバーにアクセスできることを確認します。
Webサーバー自体にはサーバー証明書をインポートしておりませんが、ALBがサーバー証明書を使って通信の暗号を代行しています。
SSL通信できることが確認できたので、必要に応じてALBのリスナーからHTTPを削除します。(EC2ダッシュボードの「ロードバランシング」→「ロードバランサー」でNetAttest-albを開き、「リスナーとルール」タブで「HTTP:80」を選択して「リスナーの管理」→「リスナーの削除」で削除できます。)

Webサーバーを全世界に公開する

ALBを使ってHTTPS通信もできるようになったので「VPCダッシュボード」の「セキュリティ」→「セキュリティグループ」を開いて「NetAttest-alb-nsg」にインバウンドルールで

タイプ	ソース
HTTPS	Anyware

にすることで、全世界からアクセスすることが可能になります。

ただし、現時点ではセキュリティ設計を行っていない Amazon Linux 上に初期状態の Nginx を構成した環境であるため、このまま公開することは、セキュリティ上のリスクを伴う可能性があります。
公開にあたっては、AWS や Web サーバー構築に関する知見を有する専門家にご相談のうえ、慎重にご判断ください。

なお、ALBにもう一工夫加えてOneGateから発行したクライアント証明書を持った端末からのみアクセス可とする方法を取ることができ、よりセキュリティ的に強固なシステムに仕上げることが可能ですので、そちらの方法も紹介できればと考えております。

記事を書いた人

ソリトンシステムズ・テクニカルチーム

ピックアップ Pick up

Pick up一覧

タグ Tag

金融流通・小売医療エネルギー運輸サービス情報通信中央省庁・独法自治体・地方公共団体教育・文教認証エンドポイントネットワークゼロトラスト販売店インタビューメーカーインタビューセミナーレポート展示会・フェアレポートサイバーセキュリティリモートアクセステレワーク社内LAN 無線LAN プロダクト検証サプリカント設定技術解説記事調査報告 Windows iOS macOS Android ChromeOS DHCP/DNS Soliton OneGate NetAttest EPS NetAttest D3 SmartOn ID InfoTrace 360 Soliton SecureBrowser Soliton SecureDesktop WrappingBox FileZen S VVAULT コラム調査レポート目次 Soliton SecureWorkspace HiQZen

OneGateから発行した証明書を使ってAWS ALBをセキュアにする-その3「公開したCRLをALBに自動反映」の画像

技術記事・調査

OneGateから発行した証明書を使ってAWS ALBをセキュアにする-その3「公開したCRLをALBに自動反映」

2025.04.23

OneGateから発行した証明書を使ってAWS ALBをセキュアにする-その2「クライアント証明書認証」の画像

技術記事・調査

OneGateから発行した証明書を使ってAWS ALBをセキュアにする-その2「クライアント証明書認証」

2025.04.23

【EPS技術記事】「Chromebook」で無線LANに接続する方法～電子証明書による認証（EAP-TLS）編～の画像

技術記事・調査

【EPS技術記事】「Chromebook」で無線LANに接続する方法～電子証明書による認証（EAP-TLS）編～

2025.03.31

AWS上にTLSで受信できるSyslogサーバーを構築する

Soliton OneGate

技術解説記事

2025.01.31

【EPS技術記事】「 macOS Sequoia 」で無線LANに接続する方法～電子証明書による認証（EAP-TLS）編～の画像

技術記事・調査

【EPS技術記事】「 macOS Sequoia 」で無線LANに接続する方法～電子証明書による認証（EAP-TLS）編～

2025.01.15

NetAttest リモート管理サービス（GIGAスクール向け）

2025.01.15

OneGateから発行した証明書を使ってAWS ALBをセキュアにする-その1「SSLオフロード」

構成

構築の流れ

ターゲットとなるWebサーバーの構築

VPCの作成

インターネットゲートウェイの作成

サブネットの作成

ルートテーブルの作成

セキュリティグループの作成

Amazon Linux 2023へSSH接続用のキーペアを作成

Amazon Linux 2023でWebサーバーを構築

NetAttet-1a-subサブネットで稼働するWebサーバー

NetAttest-1c-subサブネットで稼働するWebサーバー

Webサーバーに対してALBでロードバランシングさせる

ALB用のセキュリティグループの作成

ALBからWebサーバーにアクセスを許可する

ターゲットグループの作成

ALBの作成

ALBにHTTPSアクセスしてSSLオフロードさせる

サーバー証明書の発行

ACMにサーバー証明書を保存

HTTPSリスナーの追加

Webサーバーを全世界に公開する

ピックアップ Pick up

都築電気が提案する「リモートアクセス対策強化パッケージ」中小企業に最適なVPNセキュリティ環境｜都築電気株式会社×Soliton OneGate

ゼロトラスト強化なら国産SIEM「LogStare」─Soliton OneGate連携で認証ログの“気づき”を自動化

Cloudflare One × Soliton OneGateが実現する、戦略的なゼロトラスト環境

無線LAN+認証の導入から運用保守まですべてお任せ、月額サブスクのマネージドサービスを提供｜Cisco Meraki® × Soliton OneGate

【ウェビナー】「医療情報システムの安全管理に関するガイドライン」に基づくランサムウェア等へのセキュリティ対策と導入事例/効果について｜アクシオ×ソリトンシステムズ

「切れない」VPNに認証の側面から安心をプラス｜Absolute Secure Access ✕ Soliton OneGate

タグ Tag

関連記事

項目	値
名前	NetAttest-rt
VPC	作成済みのVPC 例)NetAttest-vpc

項目	値
送信先	0.0.0.0/0
ターゲット	インターネットゲートウェイ NetAttest-ig

項目	値
セキュリティグループ名	NetAttest-WebSrv-nsg
情報	適当な値
VPC	NetAttest-vpc

タイプ	送信先
すべてのトラフィック	カスタム 0.0.0.0/0

項目	値
Amazonマシンイメージ(AMI)	Amazon Linux 2023 AMI
アーキテクチャ	64ビット(x86)

項目	値
ユーザー名	ec2-user
認証方式	RSA/DSA/ECDSA/ED25519鍵を使う
秘密鍵	作成した秘密鍵

項目	値
セキュリティグループ名	Netattest-alb-nsg
説明	任意
VPC	NetAttest-vpc

タイプ	ソース
SSH	マイIP
HTTP	カスタムセキュリティグループ NetAttest-alb-nsg
HTTPS	カスタムセキュリティグループ NetAttest-alb-nsg

項目	値
ヘルスチェック	HTTP
ヘルスチェックパス	/

項目	値
ロードバランサー名	NetAttest-alb
スキーム	インターネット向け
ロードバランサーのIPアドレスタイプ	IPv4

項目	値
インスタンスタイプ	t2.micro

項目	値
キーペア名	NetAttest-key

項目	値
インスタンスタイプ	t2.micro

項目	値
キーペア名	NetAttest-key

項目	値
VPC	NetAttest-vpc
アベイラビリティゾーンとサブネット	ap-northeast-1a(apone1-az4)/NetAttest-1a-sub ap-northeast-1c(apone1-az1)/NetAttest-1c-sbu

項目	値
プロトコル	HTTP
ポート	80
デフォルトアクション	NetAttest-Web-target

項目	値
アクションのルーティング	ターゲットグループへ転送
ターゲットグループ	NetAttest-Web-target
重み	1

項目	値
セキュリティカテゴリ	すべてのセキュリティポリシー
ポリシー名	任意例)ELBSecurityPolicy-TLS13-2-2021-6

項目	値
証明書の取得先	ACMから
証明書	ACMにアップロードしたサーバー証明書

OneGateから発行した証明書を使ってAWS ALBをセキュアにする-その1「SSLオフロード」

構成

構築の流れ

ターゲットとなるWebサーバーの構築

VPCの作成

インターネットゲートウェイの作成

サブネットの作成

ルートテーブルの作成

セキュリティグループの作成

Amazon Linux 2023へSSH接続用のキーペアを作成

Amazon Linux 2023でWebサーバーを構築

NetAttet-1a-subサブネットで稼働するWebサーバー

NetAttest-1c-subサブネットで稼働するWebサーバー

Webサーバーに対してALBでロードバランシングさせる

ALB用のセキュリティグループの作成

ALBからWebサーバーにアクセスを許可する

ターゲットグループの作成

ALBの作成

ALBにHTTPSアクセスしてSSLオフロードさせる

サーバー証明書の発行

ACMにサーバー証明書を保存

HTTPSリスナーの追加

Webサーバーを全世界に公開する

ピックアップ Pick up

都築電気が提案する「リモートアクセス対策強化パッケージ」中小企業に最適なVPNセキュリティ環境｜都築電気株式会社×Soliton OneGate

ゼロトラスト強化なら国産SIEM「LogStare」─Soliton OneGate連携で認証ログの“気づき”を自動化

Cloudflare One × Soliton OneGateが実現する、戦略的なゼロトラスト環境

無線LAN+認証の導入から運用保守まですべてお任せ、 月額サブスクのマネージドサービスを提供 ｜Cisco Meraki® × Soliton OneGate

【ウェビナー】「医療情報システムの安全管理に関するガイドライン」に基づくランサムウェア等へのセキュリティ対策と導入事例/効果について｜アクシオ×ソリトンシステムズ

「切れない」VPNに認証の側面から安心をプラス｜Absolute Secure Access ✕ Soliton OneGate

タグ Tag

関連記事

無線LAN+認証の導入から運用保守まですべてお任せ、月額サブスクのマネージドサービスを提供｜Cisco Meraki® × Soliton OneGate