ユーザー、役割、および許可

ユーザー管理ページは、Setup > Users > Users にあります。 新しく作成されたサイトでは、このページは次のようになります（画像では、テーブルの列をいくつか省略しています）。

上の画像は、サイト作成時に自動的に作成されたすべてのユーザーを示しています。 オートメーションユーザー、その後にパスワードを使用して対話型ログインを行う単一のユーザー (cmkadmin) が続きます。 Checkmk アプライアンスでは、このユーザーの名前とパスワードはユーザー自身が定義できるため、別の名前を使用することができます。 このcmkadmin ユーザーには、以下のプロパティがあります。

新しいユーザーを作成するフォーム ( ) および既存のユーザーを編集するフォーム ( ) は、5 つのセクションに分かれています。 最初のセクションは、ID に関するものです。

Checkmk では、データセットの ID (Username) は後で変更できません。 これは、ログイン用、およびすべてのファイルとデータ構造内の内部キーとして使用されます。

メールアドレスはオプションであり、ユーザーを電子メール（SMTP 設定が必要）による通知の連絡先とする場合にのみ必要です。 同様に、Pager address フィールドは、SMS または類似のシステムによる通知用です。 独自の通知スクリプトを作成する場合は、これらのフィールドの値にアクセスして、任意の目的で使用することができます。

Monitored sites を使用すると、アクセスできる既存のサイトを任意に制限することができます。 これは、何百ものサイトを含む分散監視など、非常に大規模な環境では特に便利です。 ユーザーがホストにこれらのサイトのうち特定のサイトのみを必要とする場合、GUI は選択したサイトのみに連絡してビューを設定します。これにより、パフォーマンスが大幅に向上します。

このボックスは、ログインおよび認可用です。Automation secret for machine accounts オプションは、HTTP/HTTPS 経由で Checkmk にアクセスし、URL 経由で認証を行うアカウント用です。 その方法については、以下で説明します。

ロールは、少なくとも 1 つ選択する必要があります。 理論的には、ユーザーに複数のロールを割り当てて、 そのユーザーにすべてのロールの権限を与えることもできます。 ただし、定義済みのロールを使用する場合、これはあまり意味がありません。

disable the login to this account オプションでユーザーをロックすると、そのユーザーは アイコンでテーブルに表示されます。 そのユーザーはログインできなくなりますが、システムには残ります。 ユーザーが連絡先である場合、通知は影響を受けず、そのユーザーは引き続き電子メールなどを受信します。 ロックアウト時にユーザーがログインしていた場合、そのユーザーは自動的にログアウトされます。

1 つ以上の連絡先グループにユーザーを割り当てると、 そのユーザーは連絡先になります。新しいサイトを作成すると、 連絡先グループ「Everything 」も作成され、このグループには常にすべてのホストとすべてのサービスが含まれます。このグループに属するユーザーは 、すべてのホストとサービスを自動的に担当することになります。

「Notifications 」ボックスでは、「Receive fallback notifications 」オプションを使用して、通知ルールが適用されない場合にこの連絡先に通知を送信するように指定できます。

ユーザーは、User > Edit profile から、このボックスのすべての設定を自分で変更することもできます(Guest user ロールを除く)。 インターフェース言語の選択を除き、これらの設定はほとんど必要ありません。 詳細については、いつものようにインラインヘルプをご覧ください。

ユーザーは、User > Edit profile を使用して、インターフェースの設定を自分でカスタマイズすることもできます。 特に興味深いのは、Checkmk がインターフェースに表示する情報を増減するかどうかを決定する「Show more / Show less 」オプションです。 常にすべての情報を表示したい場合は、ここで「Enforce show more 」を選択してください。

連絡先グループは、ホストとサービス、および連絡先とを結びつけるリンクです。 各連絡先グループは、IT 環境内の特定の領域に対する責任を表します。 たとえば、連絡先グループ「SAP」には、SAP システムを保守するすべての担当者を登録し、この環境でそのようなサービスを提供するすべてのホストおよびサービスに割り当てることができます。

連絡先グループは、Setup > Users > Contact groups で管理します。 次の図は、3 つの手動で作成された連絡先グループを含むこのモジュールを示しています。

新しいグループを作成することは簡単です。 ID は常に固定され、エイリアスは後からいつでも変更可能な表示名です：

新しい連絡先グループは、連絡先もホストもサービスも含まれていないため、2 つの点で空の状態です。 連絡先グループを連絡先に割り当てるには、ユーザープロファイルを使用します。この操作は、ユーザーを編集する際にすでに説明しました。

ホストを連絡先グループに含めるには、フォルダを使用する方法とルールを使用する方法の 2 つの方法があります。 また、この 2 つの方法を組み合わせることもできます。 この場合、それぞれの連絡先グループの集約がホストに割り当てられます。

サービスがホストと同じ連絡先グループに属することは、必ずしも意味があるとは限りません。 そのため、ホストの連絡先グループとは無関係に、Assignment of services to contact groups ルールセットを使用することができます。 次のルールが適用されます。

したがって、単純な環境では、ホストにのみ連絡先グループを割り当てるだけで十分です。 さらに差別化が必要な場合は、サービスに関するルールを作成することもできます。

監視環境でホストまたはサービスの詳細を確認することで、すべてのルールとフォルダが正しく設定されているかどうかをチェックできます。 そこには、このオブジェクトの実際の割り当てをリストした「Host contact groups 」および「Host contacts 」（または「Service contact groups 」および「Service contacts 」）というエントリがあります。

通常のユーザー（Normal monitoring user ロール）は、自分が連絡先となっているオブジェクトのみを表示できることは、監視環境が大きくなるほど重要になります。 これにより、概要がわかりやすくなるだけでなく、ユーザーが関係のない場所に介入することを防ぐことができます。

管理者（Administrator ロール）は、もちろん常にすべてを表示することができます。 これは、See all host and services 許可によって制御されます。 個人設定の Visibility of hosts/services に、Only show hosts and services the user is a contact for チェックボックスがあります。 これをオンにすると、see all を自主的に放棄し、自分が連絡先となっているホストとサービスのみを表示することができます。 このオプションは、管理者であり、かつ通常のユーザーでもある、つまり 2 つの役割を持つユーザーのために用意されています。

Guest user ロールは、そのユーザーもすべてを見ることができるように事前設定されています。 ここでは、介入や個人設定は使用できません。

通常のユーザーの場合、監視環境での表示は、ユーザーが連絡先として登録されていないホストおよびサービスは、システムに存在していないように表示されるように実装されています。 とりわけ、以下のエレメントは表示を考慮しています。

前述のように、あるホストの連絡先は、そのホストのすべてのサービスの連絡先ではない場合があります。 そのような場合でも、GUI ではそのホストのすべてのサービスを確認することができます。

この例外は、通常有用であるため、デフォルトで設定されています。 実際には、これは、たとえば、実際のホストを担当する同僚も、そのホストに接続されているすべてのサービスを見ることができますが、そのサービスに関する通知は受け取らないことを意味します。

この設定が気に入らない場合は、商業版でGlobal settings > Monitoring core > Authorization settings から変更することができます。 ここで、Services の設定をStrict - Visible if user is contact for the service に変更すると、ユーザーは、そのサービスに直接連絡先として割り当てられているサービスのみを表示できるようになります。

ちなみに、これは、サービスに独自の連絡先グループが割り当てられていない場合に、サービスがホストの連絡先グループを継承することとはまったく関係がありません。 その場合は、ユーザーがサービスの連絡先となり、その通知を受信することになります。

グローバルAuthorization settings の2番目のオプションは、ホストグループとサービスグループに関するものです。 通常、グループには、そのグループのエレメントが1つ以上表示されていると表示されますが、その場合は、そのグループには、ユーザーに表示されているエレメントのみが含まれているように見えます。

Strict - Visible if all members are visible に切り替えると、少なくとも 1 つのホストまたはサービスの連絡先ではないすべてのグループが非表示になります。

この 2 つの表示設定は、通知には影響しませんのでご注意ください。

Checkmk は、ユーザーに権限を直接付与することはなく、常に役割を通じて付与します。 役割とは、権限のリストにすぎません。 役割は、ホストやサービスへの参照ではなく、権限のレベルを定義するものであることを理解しておくことが重要です。 そのためのものが連絡先グループです。

Checkmk には、削除することはできませんが、必要に応じてカスタマイズできる、以下の定義済みロールが備わっています。

ロールは、Setup > Users > Roles & permissions で管理されます。

ちなみに、新しい Checkmk サイトを作成すると、Checkmk インターフェースへのログイン用に、Administrator ロールを持つユーザー (cmkadmin) が 1 人だけ作成されます。 その他の可能なロールは、当面は使用されません。 ゲストユーザーが必要な場合は、ご自身で作成する必要があります。

通常どおり、 をクリックすると、役割の編集モードに移動します。

さまざまな許可の意味（ここでは抜粋を表示）は、インラインヘルプで確認できます。

ここでの特別な機能は、各許可について 3 つの選択肢があることです。yes 、no 、default (yes) 、またはdefault (no) です。 インストール時には、すべての値がdefault に設定されています。 認可自体に関しては、yes またはdefault (yes) のいずれを設定しても違いはありません。 ただし、Checkmk の新しいバージョンをインストールすると、デフォルト値が変更される場合があります (ただし、これはごくまれです)。 その場合、明示的に設定した設定はインストールによって影響を受けません。

さらに、この原則により、Checkmk のインストールが標準から逸脱している箇所を非常に迅速に認識することができます。

新しいロールを作成するためのボタンがないことに驚かれるかもしれません。 これには意図的な理由があります。 新しいロールは、Clone を使用して既存のロールから派生させて作成します。 新しいロールは単にコピーとして作成されるのではなく、元のロールとの関係（Based on role ）が保持されます。

この接続には重要な機能があります。 クローンした役割に対して明示的に設定されていないすべての許可 (つまり、default に設定されているままの許可) は、元の役割から継承されるからです。 その後、元の役割に変更を加えると、その変更はクローンした新しい役割にも反映されます。 元のロールにどれだけの許可があるかを考えると、これは非常に実用的です。 単純なコピーでは、自分で定義した自分のロールの特別な点を簡単に失ってしまう可能性があります。

この派生機能により、別の問題も解決されます。 Checkmk は開発が続けられているため、新しい許可が継続的に追加されています。 そのたびに、新しい許可を 3 つのロール（Administrator 、Normal monitoring user 、Guest user ）のどれに割り当てるかを決定する必要があります。 独自の役割は、あらかじめ定義された役割のいずれかから派生しているため、新しい許可は自動的に適切な値に事前設定されます。 たとえば、独自のユーザー役割を定義した場合、その役割に新しい許可が常に欠落していると、非常に不便になります。 ユーザーが新しい機能を使用できるようにするには、新しい機能ごとに役割を調整する必要があります。

個々のロールの権限を比較したい場合は、Setup > Users > Roles & permissions > Roles > Permission matrix からアクセスできるマトリックスビューが役立ちます。 このメニューオプションを選択すると、以下のビューが表示され、個々のロールの権限を比較できるだけでなく 、権限が明示的に設定されている ( ) または削除されている ( ) 場所も確認できます。

Checkmk をインストールすると、前述のように、デフォルトで管理者が作成されます。 この管理者の名前はcmkadmin です。 この管理者を使用して作業を続行することもできますが、このデフォルトの管理者を使用しない場合もあるでしょう。 たとえば、社内の規則により、複数の管理者を定義したい場合や、OWASP アプリケーションセキュリティ認証基準 (ASVS) などのセキュリティに関する推奨事項に準拠したい場合などです。

まず、管理者は他のユーザーと同様のユーザーです。 したがって、設定環境の「ユーザー管理」の章で説明したように作成します。 ただし、選択した役割によってユーザーに割り当てられる権限が優先されます。

ユーザーを作成する際に、Administrator ロールを選択してください。 その他の設定も、個人の好みや社内の規定に従って、管理者に対して行います。

Checkmk を他のシステムに接続する場合、通常は GUI を通じて行われる特定の作業を自動化したい場合がよくあります。 その例としては、次のようなものがあります。

このような場合、外部ソフトウェアは Checkmk インターフェースから特定の URL を自動的に取得できる必要があります。 もちろん、ユーザーがどのようにログインするかという問題も発生します。 通常のログインダイアログによる方法は面倒で、複数の URL を順番に取得し、クッキーを保存する必要があります。

これを簡略化するために、Checkmkではオートメーションユーザーの概念が用意されています。 これらのユーザーは、リモートコントロール専用であり、GUI による通常のログインは許可されません。 認証は、HTTP 基本認証によって行われます。

オートメーションユーザーは、TLS 暗号化データ転送のためにエージェントを Checkmk サーバーに登録するために、各 Checkmk サイトにすでに設定されています。 その他のタスクには、通常、役割「administrator.」を持つオートメーションユーザーを追加で作成することができます。 オートメーションユーザーは、通常のユーザーと同じように作成しますが、通常のパスワードではなく、オートメーションパスワード（Automation secret ）を割り当てます。 このパスワードは、cube を使用して自動的に作成することができます。

オートメーションユーザーは、通常のユーザーと同様に役割を持ち、連絡先にも設定できます。 これにより、ホストやサービスの許可や表示を必要に応じて制限することができます。

Web ページを自動的に取得するには、HTTP 基本認証のヘッダを入力します。これは、基本的に次のようになります。Authorization: Basic 1234567890abcdef 。 文字列は、username:password の Base64 エンコードされたフォームです。

オートメーションユーザーautomation およびそのオートメーションパスワードを使用して、JSON 形式でビューを取得する例を以下に示します。Base64 エンコードは curl によって行われます。

URL を取得するスクリプトが監視サイトで直接実行されている場合は、ファイルシステムからユーザーのオートメーションパスワードを直接読み込むことができます。 これはセキュリティ上の脆弱性ではなく、意図的なものです。 オートメーションパスワードを含める必要がなく、設定ファイルも不要なオートメーションスクリプトを作成することができます。 これを行うには、~/var/check_mk/web/myuser/automation.secret ファイルを読み込んでください。

このファイルの内容は、後でスクリプトで読み込めるように、シェル変数に簡単に保存することができます。

管理する監視環境がやや大規模な場合は、他の管理者にも設定、特にホストおよびサービスの管理に関わってもらいたいでしょう。 変更を行うことができるユーザーや、そのユーザーに許可する操作を管理し、ユーザー同士が互いに作業を妨害し合うことを防ぐために、フォルダに基づいて Checkmkセットアップの許可を割り当てることができます。

そのための最初のステップは、管理者同僚に、Normal monitoring user ロールに基づいて各自のユーザーを管理してもらうことです。

この役割には、基本的に設定環境の認可権限がありますが、いくつかの重要な制限があります。

フォルダや BI パックをまだリリースしていない場合、Normal monitoring user ロールを持つユーザーは、最初は変更を行うことができません。 通常の監視ユーザー用のシンプルな「Setup 」メニューは、次のとおりです。

ユーザーは、連絡先グループを介してホストを作成、編集、削除する認可を受けます。 手順は次のとおりです。

次の例は、連絡先グループ「Linux 」のすべてのユーザーがホストを管理できるフォルダのプロパティを示しています。 サブフォルダでもこれを許可するオプションが有効になっています。

連絡先グループにホストを自動的に含めるかどうかは、ユーザーで決定できます。 この例では、[Add these groups as contacts to all hosts in this folder ] オプションは設定されておらず、ホストは連絡先グループ [Linux] に追加されません。 つまり、監視環境では、連絡先グループ [Linux ] にはホストは表示されません (ルールで指定している場合を除く)。 このように、設定環境の表示 (および監視における責任) と認可は個別に設定できます。

セキュリティは、今日、最優先事項のひとつです。 そのため、一部の企業では、パスワードの取り扱いに関する一般的なガイドラインを定めています。 Checkmk では、このようなデフォルト設定を適用するためのいくつかの設定を用意しています。 その一部は、Global settings > User management > Password policy for local accounts にあります。

最初のオプションMinimum password length は、パスワードの品質を確保するためのものです。

2つ目のオプション「Number of character groups to use 」では、合計4つの文字グループが設定されています：

ここに「4 」と入力すると、パスワードには上記の各グループから少なくとも 1 文字ずつ含まれている必要があります。2 を使用すると、たとえば、パスワードが小文字だけで構成されていないことを確実に防止できます。 これらの設定は、パスワードが変更されるたびにチェックされます。

3 番目のオプション「Maximum age of passwords 」を選択すると、ユーザーは定期的にパスワードを変更する必要があります。 指定した時間が経過すると、次のページにアクセスすると、ユーザーに次のプロンプトが表示されます。

ユーザーは、パスワードを変更してからでないと続行できません。

最初のログイン時に初期パスワードの変更を要求することができます。 これは、各ユーザーのプロパティの「Security 」セクションにある「Enforce change: Change password at next login or access 」オプションで設定します。

Global settings > User management には、ユーザーのログインを規制するその他のグローバル設定があります。

Checkmk サイトのセキュリティを強化するため、Checkmk では各ユーザーに二要素認証機能を提供しています。 この二要素認証は、FIDO2/WebAuthn インターネット標準に基づいています。 認証は、従来通り、知識（パスワード）と所有物（認証要素）に基づいて行われます。

お使いのブラウザおよびオペレーティングシステムでサポートされている FIDO2 互換のハードウェアを使用できます。 YubiKey などの USB または NFC トークンが最も広く使用されています。 あるいは、時間ベースのワンタイムパスワード（TOTP）を生成する認証アプリ（スマートフォンなど）を使用することもできます。

緊急時には、コマンドラインからパスワードを変更することもできます。 これにより、cmkadmin のパスワードを紛失した場合でも対応できます。 もちろん、その前提条件として、Checkmk サーバーに Linux ユーザーとしてログインでき、omd su mysite でサイトユーザーになることができることが必要です。

パスワードは、前述のように ~/etc/htpasswd ファイルに保存されています。

パスワードの変更は、cmk-passwd コマンドで行います。 このコマンドでは、既存のパスワードは要求されません。cmk-passwd は、Checkmk の最新バージョンでパスワードを保存するために、常に安全な暗号化方法を選択します。 現在、cmk-passwd はこのために bcrypt を使用しています。 暗号化されていない、または暗号化が弱いパスワード (MD5 など) では、GUI へのログインはできません。