 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. はじめに
HTTPS 経由で Checkmk web インターフェイスを操作する場合は、サイトに関係なく、監視サーバーに以下を用意する必要があります。
Apache モジュール
mod_sslがインストールされ、有効化されていること。Apache モジュール
mod_rewriteおよびmod_headersが存在し、有効化されていること。有効なサーバー証明書があります。
サーバーが HTTPS 経由でアクセス可能であること。
この記事では、このような構成を実現するために必要なすべての事項について説明しています。
2. Apache モジュールの有効化
Checkmk インターフェースの HTTPS アクセスには、Apache モジュールmod_ssl が必要です。
また、セットアップの今後の手順では、暗号化されていないポート 80 への接続は、SSL 暗号化ポート 443 に転送されるものと想定しています。
これには、mod_rewrite モジュールが必要です。
最後に、リバースプロキシとして設定された外部からアクセス可能な Apache が、リクエストヘッダーをサイト Apache に転送するために、mod_headers が必要です。
現在インストールされている Apache モジュールは、apachectl コマンドで表示できます。古い Red Hat Enterprise Linux (RHEL) および CentOS バージョンでは、代わりにhttpd が必要になる場合があります。grep を使用して、必要な 3 つのモジュールがすべて存在しているかどうかをすぐにチェックしてください。
root@linux# apachectl -M | grep -E 'headers|rewrite|ssl'
headers_module (shared)
rewrite_module (shared)不足しているモジュールは、ほとんどのディストリビューションで、a2enmod スクリプトを使用して有効化できます。
このスクリプトは、/etc/apache2/mods-enabled フォルダにソフトリンクを作成します。
拡張子.load のファイルには、モジュールをロードするための指示が含まれており、.conf ファイルには、モジュールの実際の設定が含まれています。
root@linux# a2enmod ssl
Enabling module ssl.
To activate the new configuration, you need to run:
systemctl restart apache2RHEL の古いバージョンおよびそれに基づくディストリビューションでは、mod_ssl は別途インストールする必要がある専用パッケージです。
root@linux# yum install -y httpd mod_ssla2enmod コマンドが使用できない場合は、Apache の設定をディレクトリや多数の個別ファイルに分割せずに 1 つの設定ファイルに保存するディストリビューションを使用しています。
その場合は、/etc/httpd/conf/httpd.conf 設定ファイル内のコメントアウトされている行LoadModule ssl_module […] から# を削除する必要があります。
他の 2 つのモジュールについても、同じ手順で進めてください。
Apache web サーバーを今すぐ再起動できるかどうかは、Apache のインストール時に、単純な自己署名証明書が自動的に生成されたかどうかによって異なります。
これを確認するには、まず、証明書とキーのファイルパスが記載された設定ファイルを探し、これらのファイルが存在するかチェックします (RHEL の場合、検索の開始ディレクトリとして/etc/httpd を指定してください)。
root@linux# find /etc/apache2/ -type f -exec grep -Hn '^\s*SSLCertificate.*File' {} \;
/etc/apache2/sites-available/default-ssl.conf:32: SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/apache2/sites-available/default-ssl.conf:33: SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key設定ファイルで指定されているファイルが存在するかチェックします。 自動的に作成された証明書が存在しない場合は、証明書を受け取るか、または自分で作成してから Apache web サーバーを再起動してください。そうしないと、再起動に失敗します。
証明書とキーが存在する場合、デフォルトで使用されているsystemd の Apache web サーバーを、次のコマンドで再起動します。
root@linux# systemctl restart apache2一部のディストリビューションでは、サービスの名前としてapache2 ではなく、より一般的なhttpd を使用しています。
この場合は、コマンドを編集してください。
注：Checkmk アプライアンスでは、web インターフェイスから HTTPS を有効にしてください。
3. 証明書の取得
サーバー証明書を取得するには、基本的に以下の方法があります。
ブラウザおよびオペレーティングシステムメーカーによって信頼されているルート証明書を使用して、CSR(証明書署名要求)による証明書の発行を外部サービスプロバイダに依頼します。 この手順では、ドメインレベルだけでなく、規制上の理由から一部の業種で義務付けられている組織レベル (組織認証) およびそれ以上のレベル (拡張認証) でも証明書を検証することができます。 これらのオプションの詳細については、検証レベルをご覧ください。
Let’s Encrypt の無料証明書を使用します。 この方法では、ドメインレベルでの検証のみが可能です。 証明書を要求するには、セキュリティを保護するサーバーが外部からアクセス可能であるか、使用するドメインのパブリック DNS に（自動）エントリを作成できる必要があります。
お客様は、ご自身の認証機関(CA)となり、独自の証明書を生成します。 独自の CA のルート証明書は、CA キーで署名された証明書を使用するサーバーと通信するすべてのマシンに存在する必要があります。 独自の CA は、あらゆるドメインの証明書を発行するために使用できるため、取り扱いは高いセキュリティ基準に従って行う必要があります。
3.1. 外部のCAの使用
長い間、すべてのブラウザおよびオペレーティングシステムで受け入れられる証明書を取得する唯一の方法は、商業認証機関によって署名された証明書を取得することでした。 この手順は、特に有効期間が長い場合、現在も一般的です。
この手順では、まず、プライベートサーバーキーを生成し、そのキーの証明書署名要求(CSR) を作成して、選択したプロバイダに転送します。 プロバイダは、ドメインの所有権を検証し、そのキーで CSR を確認して、結果のサーバー証明書を送信します。
以下の例にかかわらず、必ず認証機関のガイドラインに従い、コマンドを適宜変更してください。
鍵とCSRの生成
まず、プライベートサーバーキーを生成します。 この手順は、セキュリティを保護する Checkmk サイトが置かれているサーバー上で直接実行できます。
使用するフォルダは、多くのディストリビューションではデフォルトの/etc/certs です。
ただし、Apacheプロセスが読み取りアクセスできる任意のフォルダを使用できます。
このコンテキストでは、使用するプライマリドメイン名（ここではcheckmk.mydomain.com ）をキーの名前に使用すると、概要がわかりやすくなります。
特に、後で独自のキー/証明書を使用するサーバー名が追加される場合、この命名規則を使用すると割り当てが容易になります。
秘密鍵は後でデータトラフィックを暗号化するために使用されるため、適切な注意（アクセス権など）を払ってハンドルする必要があります。 Apache サーバーを自動的に再起動できるように、ほとんどの管理者はパスフレーズを割り当てません。
root@linux# openssl genrsa -out /etc/certs/checkmk.mydomain.com.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.....++
...............................................................++
e is 65537 (0x010001)次のステップでは、証明書署名要求 (CSR) を作成します。これは、ID 証明書 (ここでは公開鍵証明書) の作成を要求するデジタル要求です。
root@linux# openssl req -new -key checkmk.mydomain.com.key -out checkmk.mydomain.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
---
Country Name (2 letter code) [AU]: DE
State or Province Name (full name) [Some-State]: Bavaria
Locality Name (eg, city) []: Munich
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Yoyodyne Inc.
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []: checkmk.mydomain.com
Email Address []: webmaster@mydomain.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:会社情報を正しく入力し、サーバー名をCommon Name として入力してください。Email Address は、同じドメイン内にあり、アクティブに読み込まれる既存のメールボックスに属している必要があります。
拡張子ファイルの作成
最新のブラウザでは、証明書が 1 つのホスト名に対してのみ発行されている場合でも、代替ホスト名用の拡張機能を使用する証明書が必要です。
そのためには、拡張ファイルが必要になりますが、一部のプロバイダでは、このファイルが自動的に作成され、統合されています。
そうではない場合や、不明な場合は、このファイルを作成してください。
証明書を複数のホスト名に対して有効にする場合は、[alt_names] の後に、必要に応じてDNS.2 = などの行を追加してください。
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = checkmk.mydomain.comドキュメントの提出
求める検証のレベルによっては、商業登記簿の抜粋や銀行データなどの追加書類を準備する必要がある場合もあります。 要求される書類、提出方法、確認方法はプロバイダによって異なるため、ここでは一般的なガイダンスは提供できません。 たとえば、拡張検証では、登録郵便でコードが代表取締役または署名権限者に送付され、その人が web インターフェイスからコードを入力しなければならない場合もあります。
ドメインレベルのみの検証という最も単純なケースでは、CSR ファイルおよび EXT ファイル（該当する場合）を web インターフェイスからアップロードします。
その後、Admin-C（ドメインの所有者）または Tech-C（ドメインの技術責任者）に登録されているメールアドレス、あるいはwebmaster@domain.com などの一般的なメールアドレスから、メールアドレスを選択することができます。
このアドレスに確認リンクが送信されます。
証明書の受領
検証プロセス自体は、ドメインレベルの検証では通常、最大で数分程度、拡張検証の場合は数日かかる場合もあります。 このプロセスが完了すると、お客様のキーに属する証明書が E メールまたはダウンロードで届きます。 証明書に加えて、証明書チェーンファイルへのダウンロードリンクも届きます。 このファイルも必ず保存してください。
3.2. Let’s Encrypt
サーバーにリモートアクセスできる場合、またはネームサーバーにアクセスできる場合は、Electronic Frontier Foundation (EFF) が運営する非営利サービスプロバイダLet’s Encrypt を利用して、証明書を自動的に生成することができます。 このサービスは無料です。 DNS 経由で検証される証明書は 90 日ごとに数分の作業が必要ですが、サーバーディレクトリ経由で検証される証明書は、何年も自動的に再生成されます。
Let’s Encrypt 証明書の場合、EFF は、さまざまなパッケージ形式で利用できる Python プログラムCertbot を提供しています。 Certbot は、キーを作成し、CSR を送信し、サーバーまたはドメインの所有権をチェックし、最後に証明書をダウンロードします。 Certbot は、自動証明書管理環境 (ACME)プロトコルを介して EFF サーバーと通信します。
Certbot スクリプトのインストール
Certbot をインストールするには 3 つの方法があります。 どの方法を選択するかは、主に使用しているディストリビューションの古さ、およびサードパーティのソースからのパッケージのインストールに関する組織のポリシーによって決まります。
お使いの Linux ディストリビューションのパッケージ管理で Certbot バージョン 1.10 以降が提供されている場合は、このバージョンの Certbot を使用できます。
Certbot は、Python パッケージインデックスから Python パッケージインストールツール
pip3を使用してインストールできます。pip3 install certbotコマンドも、必要な依存関係をすべてインストールします。EFF は、Certbot ドキュメントページにあるスナップイメージからのインストールを推奨しています。 スナップパッケージ形式の既知の長所と短所があります。
完全自動化された設定
Checkmk サーバーがインターネットからアクセス可能であり、Checkmk のインストール後にシステム全体の Apache web サーバーの設定に変更を加えていない場合は、Certbot の「Apache 自動化」を使用できます。 これを使用すると、キーの生成、証明書の要求、Apache 設定の自動調整、そして有効期間が 90 日間の証明書の有効期限が切れる前に、その更新を定期的に行うクーロンジョブを設定することができます。
root@linux# certbot --apacheスクリプトは、連絡先情報（必要な証明書の回収などの追加情報に関する E メールアドレス）およびインストールパスに関する情報を対話形式で要求します。
スクリプトが終了すると、SSL 設定が機能するようになります。mod_ssl の設定ファイルを変更する必要はありません。これは Certbot によってすでに実行されています。
半自動設定
前のセクションで説明したように証明書を要求するが、Apache の設定を自分でカスタマイズしたい場合は、次のコマンドを使用してください。
root@linux# certbot certonly --apacheその後、mod_ssl の設定ファイルで以下の手順に従って設定を完了してください。
追加のオプション
たとえば、Checkmk サーバーはイントラネットまたは VPN 経由でしかアクセスできないが、DNS サーバーは公開されている場合、DNS チャレンジによって検証することができます。 この場合、ドメインの所有権は、web サーバーにファイルを配置できるかどうかではなく、DNS にエントリを追加できるかどうかでチェックされます。 これには、ホスト名を IP アドレスに解決するエントリは含まれませんが、任意の文字列を含むことができる、いわゆる TXT エントリが含まれます。 TXT エントリは、たとえば、ドメインに対して電子メールを送信できるサーバーを指定する場合にも使用されます。
DNS チャレンジは手動で実行できますが、これは通常、有効期間が 90 日の個々のテストシステムでのみ実用的です。 DNS プロバイダが Let’s Encrypt によってサポートされている API を持っている場合は、自動更新も実行できます。 これについては、Let’s Encrypt のチャレンジタイプの概要をご覧ください。
3.3. 内部 CA の使用
ユーザーは、認証機関 (CA) の役割を引き受け、任意のドメイン (自社のドメイン、外部ドメイン、および架空ドメイン) に対して証明書を発行することができます。
独自の CA 経由のルートは、テスト環境や、ユーザー数が管理可能な孤立した Checkmk サーバーに特に有用です。
また、5 つの予約済みトップレベルドメイン (TLD).example 、.invalid 、.local 、.localhost 、.test を内部で使用している場合、証明書を取得する唯一の手段でもあります。
これらのドメインにはレジストラがないため、所有権を検証することはできません。
この章では、このような内部 CA を使用して証明書を発行する方法について説明します。 前提条件として、プライベート CA ルートまたは CA 中間キーをすでに取得しており、それを使用して Checkmk サーバーを保護するための証明書を発行する必要があることを想定しています。
CA キー、CA 証明書、および関連する設定ファイルの作成については、このチュートリアルでは説明しません。
キーとCSRの生成
サーバーキー、証明書署名要求 (CSR)、および拡張ファイルを作成するには、「商用 CA による証明書の発行」のセクションの説明に従ってください。 手順と必要なファイルは同じです。
CSR の署名
証明書に自分で署名するには、少なくとも秘密鍵 (ここではintermediate.key.pem) と、対応する中間証明書intermediate.pem が必要です。
構成ファイルも持っている場合は、そのパスを--config パラメータで指定する必要があります。
CSR ファイルcheckmk.mydomain.com.csr 、拡張ファイルcheckmk.mydomain.com.ext 、および出力ファイルcheckmk.mydomain.com.crt に基づく署名は、次のコマンドで実行されます。
user@host:~$ openssl x509 -CAcreateserial -req \
-in checkmk.mydomain.com.csr \
-CA intermediate.pem -CAkey intermediate.key.pem \
-out checkmk.mydomain.com.crt -days 365 \
-sha256 -extfile checkmk.mydomain.com.extここで作成したサーバー証明書checkmk.mydomain.com.crt に加えて、CA 証明書intermediate.pem も渡す必要があります。
ルート CA ではない場合は、ルート証明書（以下、ca_certificate_internal.pem と表記）も転送する必要があります。
証明書のインポート
CA 証明書を信頼済みとしてインポートするオプションは、ブラウザによって異なります。
通常、証明書ca_certificate_intern.pem をSettings > Privacy およびSecurity > Certificates > Import に追加するだけで十分です。
商業版でエージェントが自動的に更新される際に、証明書管理が障害にならないように、エージェントベーカリーでは、エージェントの更新にのみ使用される独自の CA 証明書を渡すオプションを用意しています。 この場合、システム証明書は変更されず、エージェントの更新は引き続き可能です。
エージェントアップデートによる配布の代替手段として、ルート証明書をホストのローカル CA データベースに統合することができます。
これを行うには、ca_certificate_intern.pem ファイルを/usr/local/share/ca-certificates/ にコピーし、キャッシュを再生成します。
root@linux# update-ca-certificatesWindows では、MMC の「証明書」スナップインを使用してシステム証明書を管理することができます。 これは、たとえば、Microsoft ブラウザを使用して、独自の CA でセキュリティ保護された Checkmk にアクセスする場合などに必要です。 正確な手順については、Microsoft サポート技術情報 PKI の記事をご覧ください。 または、Intune を使用して証明書を配布することもできます。
4. サイトへの HTTPS 接続の設定
まず、SSL 設定ファイルで、鍵、証明書、中間証明書の正しいファイルパスを指定する必要があります。これらは、apache2 web サーバーの設定であり、Checkmk 独自のものではないことにご注意ください。したがって、Debian ベースのシステムで使用される設定ファイルは、通常、デフォルトの/etc/apache2/sites-enabled/default-ssl.conf ですが、古いディストリビューションではファイルパスが異なる場合があります。
以下の例では、SSLCertificateKeyFile は、このサーバーの初期設定時に生成された秘密鍵を表しています。SSLCertificateChainFile には、中間証明書、または該当する場合は、依存する中間証明書の連結が含まれています。
これは、CA キーが署名に直接使用される内部 CA の場合にのみ省略されます。
多くの商用ベンダーは汎用的なファイル名を使用しているため、これらを採用する場合、設定は次のように類似します：
SSLEngine on
SSLCertificateKeyFile /etc/certs/checkmk.mydomain.com.key
SSLCertificateChainFile /etc/certs/ca_bundle.crt
SSLCertificateFile /etc/certs/certificate.crtLet’s Encrypt を使用して証明書を生成したが、手動で設定を更新したい場合は、/etc/letsencrypt/live に保存されているファイルパスを特定し、次のように入力してください。
SSLEngine on
SSLCertificateKeyFile /etc/letsencrypt/live/checkmk.mydomain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/checkmk.mydomain.com/chain.pem
SSLCertificateFile /etc/letsencrypt/live/checkmk.mydomain.com/cert.pem4.1. HTTPS 転送の追加
Apache は、仮想ホストを使用して、1 つの IP アドレスで複数のホスト名に対するコンテンツを提供します。
Apache のコンテキストで「サイト」という用語が使用されている場合は、Checkmk サイトではなく、このような仮想ホストを指します。
専用の Checkmk サーバーでは、通常、サーバー名を持つ 1 つの仮想ホストのみが使用され、その下ですべての Checkmk サイトにアクセスできます。VirtualHost の設定は、使用しているディストリビューションに応じて、次のいずれかのファイルにあります。
Debian、Ubuntu |
|
RHEL、CentOS |
|
SLES |
|
次の例では、ポート 80 での暗号化されていない接続と 443 での暗号化された接続に 1 つの設定ファイルを使用すると仮定しています。
この場合、VirtualHost セクションに次の行を追加してください。
RewriteEngine On
# Never forward request for .well-known (important when using Let's Encrypt)
RewriteCond %{REQUEST_URI} !^/.well-known
# Next 2 lines: Force redirection if incoming request is not on 443
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}$1 [L]
# This section passes the system Apaches connection mode to the
# instance Apache. Make sure mod_headers is enabled, otherwise it
# will be ignored and "Analyze configuration" will issue "WARN".
<IfModule headers_module>
RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
</IfModule>ここにある 2 行のRequestHeader set X-Forwarded… により、ポート 5000 の Site Apache にSSL 経由で呼び出しがあったことが通知され、セキュリティルールが順守されていることが確認されます。
設定の変更後、web サーバーを再起動する必要があります。
root@linux# systemctl restart apache2一部のディストリビューションでは、サービス名としてapache2 ではなく、より一般的なhttpd を使用しています。
その場合は、コマンドを編集してください。
5. 追加オプション
5.1. HSTS の設定
Checkmk サーバーを HTTPS 経由でのみアクセス可能にするのは、監視への接続をセキュリティで保護するための最初で最も重要なステップです。 ただし、追加のオプション設定により、セキュリティをさらに強化することができます。 たとえば、web サーバーは、今後 HTTPS 経由でのみアクセス可能であり、HTTP によるセキュリティで保護されていない接続は常に拒否されることをブラウザに通知することができます。
この手法は「HTTP Strict Transport Security」（HSTS）と呼ばれ、秒単位で一定期間設定されます。 この期間が経過すると、ブラウザは HSTS による制限がまだ有効であるかどうかを再度チェックします。
HSTSの機能
HSTS を設定すると、安全な接続のみを使用できるようになるという利点があるだけでなく、その使用には特定の条件があるため、スイッチを切り替える前にその条件を確認しておく必要があります。
HSTS へのエントリがユーザーのブラウザによって作成されると、そのエントリは、少なくとも指定した時間が経過するまでは、そのブラウザに関する詳細な知識がない限り削除できません。これは多くのユーザーには当てはまらないことにご注意ください。
証明書が有効期限切れになっている、または自己署名証明書に置き換えられているなどの場合、接続は拒否されます。 このようなページは、証明書の一時的な信頼の例外設定を行っても、バイパスすることはできません。
逆に、HSTS は、接続が最初に確立されたときに証明書が信頼されている場合にのみ考慮されます。 それ以外の場合、ブラウザは HSTS のエントリを作成しないため、追加の保護メカニズムは使用されません。
Apache web サーバーの設定
このオプションを設定するには、HTTPS 設定に次のエントリを追加します。
Debian/Ubuntu では、デフォルトでは、これはdefault-ssl.conf ファイルです。
Header always set Strict-Transport-Security "max-age=43200"重要：まず、設定をテストするために、600 秒などの短い期間を設定してください。そうしないと、エラーが発生した場合に接続が永久的に拒否される可能性があります。 詳細については、以下の「特殊機能」をご覧ください。
新しい設定が機能しているかどうかを確認するには、curl プログラムを使用してサーバーを取得します。
この例では、出力の最初の 4 行のみを表示しています。
root@linux# curl -I \https://mycmkserver/mysite/check_mk/login.py
HTTP/1.1 200 OK
Date: Tue, 01 Jun 2021 09:30:20 GMT
Server: Apache
Strict-Transport-Security: max-age=3600