認証とセキュリティ（SSO を含む）

初期状態では、全員がユーザー名とパスワードでサインインします。ユーザー名の代わりに、メールアドレスも使えます。メールの送信を設定してあれば、フォームの下に「Do you need a password reset?」のリンクが表示されます。メールの送信は Professional に含まれます。

サインインすると、ブラウザーに一定時間有効な通行証が渡されます。その長さは「JWT token timer」のカードで決めます。1から24時間まで指定でき、推奨は12です。その後は、もう一度サインインが必要になります。

「Password policy」のカードは、システム内で設定されるすべてのパスワードに適用されます。アカウントの作成時、本人によるパスワードの変更時、管理者による初期化時に適用されます。

最小の長さ、必要な文字の種類、パスワードが何日で期限切れになるか、古いパスワードを何個まで使えなくするかを設定します。日数と使用禁止の個数は、0 が「なし」を意味します。

大文字と小文字の規則が、特定の言語を締め出すことはありません。多くの文字体系にはそもそもこの区別がなく、そうした文字は1文字で両方の規則を満たします。

SSO やディレクトリだけでサインインするアカウントには、この場所のパスワードがないため、期限切れは適用されません。その規則は提供元にあります。既存のアカウントを SSO に結び付けても、そのアカウントに独自のパスワードが残っていれば、そのパスワードには期限切れとパスワードポリシーが引き続き適用されます。

「2FA Settings」のカードで、二要素認証を使わなければならない人を決めます。「Two-factor requirement」で、4つの段階から1つを選びます。「Off」「Administrators only」「Administrators and agents」「Everyone」です。「Everyone」には顧客も含まれます。新しいインストールは「Administrators only」で始まります。以前からあるインストールは、アップデート後もそれまでの設定を保ちます。

次にサインインする人は、第二の要素がまだなければ、それを設定します。システムは認証アプリ用の QR コードと、手で入力するための同じキーを表示します。最初のコードを入力すると、要素が有効になります。「Set up later」で設定を後回しにでき、サインインはそのまま続きます。後回しにできるのは、最初に後回しにした日から数えて最大7日間です。ボタンの下の行に残りの日数が表示されます。その後は設定が必須になります。

その直後に、10個の回復コードが表示されます。それぞれ、アプリのコードの代わりに一度だけ使えます。表示されるのは、ちょうど一度だけです。「Copy」または「Download」で保存します。「Download」は常に使えます。「Copy」もたいてい使えます。

端末とコードの両方を失った場合は、管理者が助けます。利用者の一覧で斜線の入った盾のボタンを押すと、その人の二要素認証が初期化されます。次のサインインで、もう一度設定します。

コードはサーバーの時計に依存します。時計が狂っていると、どのコードも受け付けられません。同じカードの「Check now」ボタンで、サーバーの時刻を公開の時刻源と照合できます。

外部のサインインサービスを通って入る人に、システムはコードを求めません。第二の要素は、すでに提供元が確認しているためです。ディレクトリでのサインインは違います。そこでは、上の規則がそのまま適用されます。

どのユーザーも、自分のアカウントで二要素認証をオンにできます。これはどのロールでも同じで、「2FA Settings」のカードが求めていないときも使えます。サイドバー左下の利用者メニューを開き、「Profile picture」を選びます。同じページに「Two-factor authentication」の欄があります。

この欄には、二要素認証がオンかどうかが表示されます。オフの間は「Turn on」ボタンがあります。最初にパスワードを尋ねられます。次に、認証アプリ用の QR コードと、手で入力するための同じキーが表示されます。アプリの最初のコードを入力すると、要素が有効になります。

その直後に、10個の回復コードが表示されます。「Copy」または「Download」で保存してください。「I have saved my codes」で一覧が閉じます。一覧が表示されるのは、この一度だけです。

二要素認証がオンの間、この欄には回復コードの残り数が表示されます。「New recovery codes」は新しいコードを10個作ります。古いコードはそのときから使えなくなります。「Turn off」で二要素認証を再びオフにします。どちらのボタンも、アプリの現在のコードを求めます。そこでは回復コードは受け付けられません。

「2FA Settings」のカードがあなたのロールに二要素認証を求めている場合、「Turn off」はありません。欄の中の1行がそのことを伝えます。

誤ったパスワードや誤ったコードは、失敗したサインインとして数えられます。つまり、パスワードの推測に対する防御はここでも働きます。オンとオフの切り替えはセキュリティログに記録されます。管理者が自分の二要素認証をオフにすると、ログが警告を出します。

外部のサインインサービスだけでサインインするアカウントには、ボタンの代わりに一文が表示されます。第二の要素は、そのサービスの提供元が扱います。ディレクトリのアカウントは、最初の手順でディレクトリのパスワードを入力します。

この防御は、設定なしで動きます。オンにする操作はありません。その説明は「2FA Settings」のカードにあります。

働き方は二段階です。同じアカウントで5回失敗すると、その接続元のアドレスが止められます。この停止は、遅くとも最初の失敗から15分後に終わります。ほかのアドレスからは、そのアカウントをすぐに使えます。

ここが大事な点です。そうしなければ、サインイン名を知っている人が、間違ったパスワードを5回入れるだけで同僚を締め出せてしまいます。パスワードを知る必要すらありません。

二段階目はアカウント自体です。20回失敗すると、15分間施錠されます。1つのアドレスから数えられるのは最大5回なので、これには複数のアドレスが必要です。

サインインに成功すると、両方の数え上げが元に戻ります。サーバーを再起動すると、アドレスの停止は消えますが、アカウントの施錠は残ります。ディレクトリでのサインインにも、同じ数え上げが適用されます。ディレクトリにつながらない場合は、失敗には数えません。その名前のアカウントがチケットシステムにまだない場合は、アドレスの停止だけが適用されます。

この形で施錠されたアカウントには、利用者の一覧で「temporarily locked」のバッジが付きます。一覧からは消えません。15分後、バッジは自動的に消えます。

待つ必要はありません。同じ行に、開いた錠前のボタンがあります。押すと施錠がすぐ解け、両方の数え上げも消えます。

これは「Archive」とは違います。あちらはアカウントを完全に停止するもので、スタッフ枠を取ったり空けたりするのは、そちらだけです。

セキュリティログは2種類のイベントを記録します。「Sign-in」の領域には、失敗したサインイン、ロックされたアカウント、ロック中のサインイン試行、拒否された2段階認証コード、パスワードの変更が入ります。これは、パスワード、ディレクトリ、SSO のどれによるサインインにも当てはまります。

「Administration」の領域には、誰が何を変更したかが表示されます。対象は、アカウント、役割、権限、セキュリティ設定、アーカイブです。ログのエクスポートも、すべてそこに記録されます。

成功したサインインが記録されるのは、2つの場合だけです。1つ目は管理者の場合です。2つ目は、同じアカウントで失敗した試行の後のサインインです。エージェントや顧客の通常のサインインは、ログに記録されません。このログは出勤簿ではありません。

存在しない名前でサインインしようとすると、記録には「unknown account」と表示されます。入力された名前は保存されません。それが誤った欄に入力されたパスワードであることもあるためです。

サインインイベントには、IP アドレスとブラウザーが保存されます。管理操作には、誰が実行したかが保存されますが、IP アドレスは保存されません。パスワード、コード、チケットやメールの内容がログに入ることはありません。

ページには新しい記録から順に、1ページに50件ずつ表示されます。「Filters」カードでリストを絞り込みます。「Area」ではサインインか管理かを、「Event」では1種類のイベントを選びます。「Person」は、操作した人と影響を受けた人の名前を検索します。「From」と「To」で日付を限定します。「Failures only」は、成功したものをすべて隠します。

フィルターは「Apply」をクリックして初めて有効になります。「Reset」でフィルターを外します。

「Export CSV」と「Export PDF」は、フィルターで表示されている内容をそのままダウンロードします。1つのファイルに入るのは最大10,000件です。フィルターに合う記録がそれより多い場合は、エクスポートボタンのそばに注意書きが出ます。PDF はあなたの言語で作られ、上部にフィルターと期間が記載されます。日付と時刻は、「Settings → General Settings」で設定した形式になります。

CSV ファイルは常に英語で、時刻は UTC です。そのため、プログラムは言語に関係なく読み込めます。エクスポートそのものも、「Security log exported」としてログに記録されます。

6種類のイベントでアラートが出ます。失敗した試行の後にロックされたアカウント、「Admin」に変更された役割、最初から「Admin」の役割で作成されたアカウント、管理者の2段階認証のリセットです。さらに、稼働中のデータから削除されたアーカイブ済みチケットと、失敗した試行の後の管理者のサインインが加わります。

アラートの後は、権限を持つ全員の画面で、各ページの上部に黄色のバナーが表示されます。バナーには、前回ログを見てからのアラートの件数が表示されます。「Open security log」のリンクからログに移動できます。ログを開くと、バナーは消えます。初めて見る前は、直近7日間のアラートを数えます。

さらに、権限とメールアドレスを持つ有効なアカウントには、アラートメールが届きます。システムは15分ごとにアラートをまとめ、イベントごとではなく1人に1通のメールを送ります。メールには、イベント、影響を受けた人、時刻が記載されます。IP アドレスは含まれません。アラートメールは Professional の機能です。

古い記録は夜間の実行で削除されます。期間は「Settings → Security」の「Data protection」カード、「Security log retention」ブロックにあります。サインインイベントの保存期間は既定で90日で、7〜365日に設定できます。管理操作の保存期間は既定で12か月で、1〜120か月に設定できます。

それぞれの期間には専用のスイッチがあります。「Delete old sign-in events」と「Delete old administrator actions」です。スイッチがオフの場合、その記録は残ります。夜間の実行については「保存期間」カードで説明しています。

データ開示の請求では、その人が操作した記録と、その人が影響を受けた記録がすべて渡されます。IP アドレスとブラウザーが含まれるのは、本人がきっかけとなった記録だけです。たとえば本人のサインインです。その人が匿名化されると、システムはその人のサインインイベントを削除します。その人の管理操作は残ります。そこでの名前はプレースホルダーに置き換えられます。

運用者であるあなたへの注意です。成功したサインインがログに入るのは、管理者の場合と、失敗した試行の後だけです。それでもログには、誰がいつ何をしたかが表れます。そのため、従業員代表のいる会社では、このログは共同決定の対象になります。

いちばん上に「Enable single sign-on」の親スイッチがあります。オフの間は、ユーザー名とパスワードのままです。その下で設定した内容は保存され、スイッチをオンにしたときに初めて効きます。

「Active Directory / LDAP」のカードで、社内のディレクトリをつなぎます。サーバー、検索の起点、人を見つけるためのフィルター、メールアドレスと氏名の項目名を入力します。

検索に使うアカウントは任意です。指定しなければ、システムは匿名で問い合わせます。本人のパスワードはディレクトリへの接続にだけ使われ、保存されることはありません。

ディレクトリ自体は、第二の要素を持ちません。セキュリティのページで二要素認証を必須にしていれば、これらの人にも求められます。

「Identity providers」のカードに、外部のサインインサービスが並びます。それぞれにタイルが1つ、サインイン画面のボタンが1つ与えられます。「Add provider」で新しく作ります。

「Provider type」で種類を選びます。「Generic OIDC Provider」は、Google Workspace、Microsoft Entra ID、Okta、Keycloak、Auth0、Ping Identity などに合います。「SAML 2.0 Provider」は、同じ提供元を SAML でつなぐ場合に合います。

そのほかに、地域向けのサービスが6つあります。LINE、Kakao、Naver、WeChat、WeCom、DingTalk です。アドレスはあらかじめ用意されており、欄の中に薄い文字で表示されます。

「Display name」に入れた名前が、あとでボタンに表示されます。その横のスイッチは、この提供元だけに適用されます。

折り返し先のアドレスは、次の順番で作業してください。まず名前だけを入力し、「Save provider」をクリックします。そこで初めてシステムが提供元の番号を知り、「Redirect URI」に完成したアドレスを表示します。このアドレスは、このインストールの公開アドレス、つまり「Settings → Security」に保存したアドレスから作られます。これは、誰かがサインインするときにシステムが使うアドレスと、まったく同じです。

そのアドレスをコピーして、提供元に登録します。提供元側では、1文字も違わずに一致している必要があります。その代わりに提供元から ID とシークレットが渡されるので、「Edit」からここに入力します。

「Allowed e-mail domains」の欄で、この提供元から入れる人を絞り込みます。空欄にすると、すべてのドメインが許可されます。

設定に足りないものがある提供元のタイルには、赤い「Incomplete」のバッジが付きます。その提供元は、サインイン画面に表示されません。横の文が、その種類にどの欄が必要かを示します。

設定の完了した提供元も、親スイッチがオフの間は表示されません。タイルの黄色い行に、そう書かれています。

ライセンスが Basic に戻っても、SSO とディレクトリでのサインインは引き続き使えます。そのときこのページでできるのは、提供元とディレクトリをオフにすることだけです。サインインの試行の記録は、引き続き読めます。

「Automatically create accounts on first sign-in」のスイッチは、親スイッチと同じカードにあります。初期状態ではオンです。

ある提供元を通して初めてサインインすると、システムはまず、その提供元にすでにひも付いたアカウントを探します。見つからなければ、新しく作ります。

新しいアカウントには「Customer」の役割が付き、チームは付きません。顧客はチケットを作るのに所属を必要としないため、すぐに作業を始められます。

顧客はどちらのエディションでも無制限なので、この形で作られたアカウントはスタッフ枠を使いません。エージェントにする人には、あとから利用者の管理で役割を与えます。

同じメールアドレスのアカウントがすでにある場合は、2つが結び付けられます。これは、提供元がアドレスを確認済みとして知らせた場合にだけ起こります。そうでなければ、サインインは拒否されます。

オフにすると、すでにアカウントを持つ人だけが入れます。それ以外の人は入れません。

いちばん下の「Recent sign-in attempts」カードには、SSO とディレクトリによる直近100件のサインインイベントが表示されます。これはセキュリティログから取られています。失敗した試行は必ず表示されます。成功したサインインが表示されるのは、管理者の場合と、同じアカウントで失敗した試行の後だけです。そのため、すべてのサインインがリストに出るわけではありません。

各行に、時刻、提供元、結果、接続元のアドレスが並びます。失敗した試行では、その理由も横に出ます。「User」の列には、アカウントの名前が表示されます。アカウントがない場合は提供元が知らせたアドレスが、それもなければ「unknown account」が表示されます。入力された名前は保存されません。

ユーザー名とパスワードによるサインインは、この表には出ません。SSO ではないためです。セキュリティログで確認できます。

初期設定では、記録は90日後に削除されます。カードのタイトルの下の文に、設定した期間が表示されます。この設定は「保存期間」のカードで説明しています。

インストール後、チームはどのウェブブラウザーからでもシステムを使えます。インストーラーは、システムへの接続方法を尋ねます。Windows のインストーラーでは、「アクセス方法」のページで選びます。Linux では、install.sh が同じことを尋ね、選択肢に1から5の番号を付けます。後から「SMITEY へのアクセス方法を変更」で変更できます。データはそのまま残ります。

「ローカルネットワーク内で IP アドレスのみ（HTTP）- 最も簡単な方法です」が既定の設定です。チームは、http:// にサーバーの IP アドレスとポートを続けたアドレスでシステムを開きます。たとえば http://192.168.1.20:8088 です。別のポートを選ばない限り、ポートは8088です。ポート80も使えます。その場合、アドレスにポートは要りません。この選択肢には、名前も証明書も要りません。

「ローカルネットワーク内で独自の名前（HTTP、HTTPS は後から可能）- 社内 DNS がある場合」は、1つ目と同じように動きますが、ticket.company.local のような名前を使います。名前は、社内 DNS で自分で作成します。その名前はサーバーの IP アドレスを指します。その後、チームは名前でも、引き続き IP アドレスでもシステムに接続できます。インストーラーは、この名前を使ったアドレスを表示します。

HTTP の2つの選択肢では、パスワードやチケットは平文のままネットワークを流れます。その場合、管理者にはページの上部にお知らせが表示されます。

残りの3つの選択肢は HTTPS を使います。「公開ドメインで HTTPS（Let's Encrypt により自動）」「ローカル ネットワーク内で HTTPS、お客様自身の証明書を使用」「ローカル ネットワーク内で HTTPS、SMITEY が作成する証明書を使用」です。これらには、サーバーのポート80と443が必要です。次のカードで説明します。

最初のテストなら、1つ目の選択肢で十分です。ネットワークに社内 DNS があれば、2つ目を選んでください。インターネットからシステムに接続できるようにするなら、公開ドメインを選んでください。自社に独自の CA があれば、ローカル ネットワーク内で自分の証明書を使う選択肢を選んでください。それ以外の場合は、SMITEY に証明書を作成させてください。

HTTPS がないと、パスワードやチケットは平文のままネットワークを流れます。新しいインストールは通常の HTTP で始まるので、どのウェブブラウザーからでもすぐに使えます。管理者が通常の HTTP でシステムを開いている間は、ページの上部にお知らせが表示されます：「This connection is not encrypted.」サーバー自身で「localhost」として開いた場合は、お知らせは表示されません。エージェントと顧客には一切表示されません。

「How to switch on HTTPS」はこのカードに移動します。「Hide for 30 days」で、あなたに対するお知らせを隠します。この設定はアカウントに属するので、別のブラウザーでも有効です。30日後、接続がまだ暗号化されていなければ、お知らせが再び表示されます。

SMITEY のインストーラーは、3つの方法で HTTPS を設定します。Windows のインストーラーでは「アクセス方法」のページで選び、Linux では install.sh が同じことを尋ねます。すでに動いているシステムでは、Windows のデスクトップかスタートメニューにある「SMITEY へのアクセス方法を変更」を開きます。Linux では、下のコマンドが同じことをします。データはそのまま残ります。

「ローカル ネットワーク内で HTTPS、お客様自身の証明書を使用」は、自社の CA などから得た自分の証明書を使います。インストーラーは、システムの名前と、証明書ファイルとその鍵を尋ねます。パスワード付きの PFX ファイルも使えます。何かを変える前に、証明書を確認します。鍵が対応していること、証明書が有効であること、名前が証明書に含まれていることが必要です。

「ローカル ネットワーク内で HTTPS、SMITEY が作成する証明書を使用」には、自分の証明書は要りません。SMITEY が自分で証明書を作り、更新も自分で行います。インストーラーは、ルート証明書を SMITEY-root-ca.crt という名前でインストールフォルダーに保存します。このファイルを、グループポリシーなどで各コンピューターに信頼されたルート証明書としてインストールしてください。それまでは、ブラウザーに警告が表示されます。

「公開ドメインで HTTPS（Let's Encrypt により自動）」は、Let’s Encrypt から証明書を取得します。サーバーを指す公開ドメインが必要です。そのため、サーバーにインターネットから接続できる必要があります。

ローカル ネットワーク内の2つの選択肢では、名前は ticket.company.local のような名前、helpdesk のような1語、または IPv4 アドレスにできます。3つの方法とも、サーバーのポート80と443が必要です。別のプログラムがそれを使っていると、インストーラーは中止し、何も変えません。その後、システムには https:// に名前を続けたアドレスで、ポートなしで接続します。

自分の証明書は、いつか期限が切れます。30日前から、管理者にはページ上部に日付付きのお知らせが表示されます。7日前からは赤になります。Professional では、メールアドレスを持つすべての管理者に、30日前と7日前にメールも届きます。更新するには、「SMITEY へのアクセス方法を変更」をもう一度開き、自分の証明書を使う選択肢を選んで、新しいファイルを指定します。

インストールに付属する HTTPS-GUIDE.txt ファイルに、すべての手順が書かれています。ルート証明書の配布と、手作業の手順も含まれます。