Tsurugi（劔）のセキュリティ設定入門：認証を有効にする

ここまで3回にわたって、国産DB「Tsurugi（劔）」を動かし、前回の「PythonでTsurugi（劔）に接続してみる」でPythonから接続するところまで見てきました。検証環境で動いた、Pythonからデータが取れた——ここで満足してしまう方も多いと思います。

ただ、検証で終わらせず社内システムや外部公開まで見据えるなら、次に確認すべきはセキュリティ設定です。今回はシリーズ最終回として、Tsurugiのデフォルト状態にどんなリスクがあるのか、認証と通信の暗号化をどう有効にするのかを整理します。目的は脅すことではなく、知らないまま外部に公開してしまう事故を防ぐための前提知識づくり。そんなつもりで読んでもらえればと思います。

なお本記事の内容は執筆時点（2026年7月、Tsurugi v1.11.x系）の情報です。設定項目はバージョンごとに変わりやすいので、実際に手を動かす際は必ずお使いのバージョンの公式GitHub（project-tsurugi/tsurugidb）で最新情報を確認してください。

Tsurugiのデフォルトは「認証なし」と心得る
セキュリティ設定の第一歩：認証を有効にする
ユーザー認証の方式を知っておく
通信の暗号化（TLS）についても知っておく
中小企業がTsurugiのような新しいOSSを扱う際の心構え
まとめ

Tsurugiのデフォルトは「認証なし」と心得る

まず押さえておきたい事実がひとつあります。Tsurugiは初期設定のまま起動すると、認証機能が無効な状態です。公式の設定パラメータ一覧（config-parameters.md）を確認すると、認証を司るenabledパラメータの初期値は明確にfalse。つまり接続先とポートさえ分かれば、誰でもデータの読み書きができてしまう状態が「デフォルト」というわけです。

これは別にTsurugiの設計ミスではありません。PostgreSQLやMySQLも、初期のインストール直後は緩めの設定になっていることが多く、運用者側で締める前提の作りが一般的です。検証用の閉じたネットワーク（インターネットから直接アクセスできない環境）で使う分には、正直この状態でも問題は起きにくいでしょう。

注意が必要なのは、クラウドサーバーに立てた環境や、社内LANの中でも他部署からアクセスできるネットワークに置く場合です。「とりあえず動かしてみよう」でポートを開けたまま放置してしまうケース。Tsurugiに限らず、どんなミドルウェアでもよくある話です。私はこれまで、開発用に立てたDBサーバーが検証終了後もそのまま残り、誰も認証を設定していなかった、という現場に何度か出くわしています。

私の考えは単純です。開発中は認証なしのままでも構いませんが、社内データを一件でも入れる段階になったら、真っ先に認証を有効化する。この順番だけは崩さないようにしています。

セキュリティ設定の第一歩：認証を有効にする

Tsurugiの設定は$TSURUGI_HOME/var/etcにあるtsurugi.iniの[authentication]セクションで行います。公式ドキュメントによると、主な項目は次の4つです。

パラメータ	デフォルト値	内容
`enabled`	`false`	認証機能を使うかどうか
`url`	`http://localhost:8080/harinoki`	認証サービスのURL
`request_timeout`	`0`（タイムアウトなし）	認証サービスへの問い合わせのタイムアウト秒数
`administrators`	`*`（全ユーザー）	管理者として扱うユーザー名（カンマ区切り）

実際に有効化する場合の設定例は次のようになります。

[authentication]
enabled = true
url = http://localhost:8080/harinoki
request_timeout = 0
administrators = admin_user1,admin_user2

ポイントは2つあります。1つ目は、認証を使うにはharinokiという付属の認証サービスを別途起動しておく必要がある点。urlは、そのharinokiがどこで待ち受けているかを示す設定です。2つ目はadministratorsの扱い。デフォルトの*のままだと、ログインできた全ユーザーが管理者権限を持ってしまいます。実際に運用するなら、管理者にしたいユーザー名を明示的に指定しておくのが安全でしょう。

この設定項目は、私が確認した限りではv1.11.x系の情報です。ちなみに認証・権限管理機能そのものは2025年9月リリースのv1.6.0で追加された、まだ新しい機能。当時の公式リリースノートには「試験的機能」と明記されていました。執筆時点までの範囲では正式機能への格上げを示す記述は見当たりません。今後も仕様変更の余地がある機能として、慎重に扱っておくのが無難でしょう。新しいOSSは機能追加のたびに設定名が変わることも珍しくないので、手順書を鵜呑みにせずtsurugi.iniのサンプルファイルや公式のconfig-parameters.mdを都度見比べる習慣をおすすめします。

ユーザー認証の方式を知っておく

Tsurugiに接続するJava向けライブラリ「Tsubakuro」やJDBCドライバでは、いくつかの認証方式（Credential）が用意されています。執筆時点で確認できた公式ドキュメントの情報をもとに整理すると、次の4種類です（クラス名など細部の呼び方は今後変わる可能性があります）。

認証なし（NullCredentialなど）：認証機能自体を使わない、いわば「素通り」の接続方式
ユーザー名とパスワード（UsernamePasswordCredentialなど）：一般的なID・パスワードでのログイン
認証トークン（RememberMeCredentialなど）：一度取得したトークンを使い回す方式
認証ファイル（FileCredentialなど）：暗号化された認証情報ファイルを指定する方式

実務で一番使いやすいのは、最後の認証ファイルだと思います。付属のコマンドラインツールtgctlにはcredentialsというサブコマンドがあり、暗号化されたローカル認証ファイルを作成できます。

tgctl credentials --user example

実行するとパスワード入力を求められ、~/.tsurugidb/credentials.keyに暗号化済みのファイルが生成されます（保存先や有効期限はオプションで変更可能。有効期限のデフォルトは90日です）。第3回のPython接続編でお見せしたサンプルコードは、接続時にパスワードを直接コードへ書く形でしたが、あれは検証用の最短ルートだったからこそ許される書き方です。本番のスクリプトやバッチ処理に組み込むなら、この認証ファイルを使ってパスワードを平文でソースコードに残さない工夫をしておくべきでしょう。

通信の暗号化（TLS）についても知っておく

認証を有効にしても、通信そのものが平文（暗号化されていない状態）だと、ネットワーク経路上でデータやパスワードを盗み見られるリスクは残ります。Tsurugiには[grpc_server]セクションに、TLS（通信を暗号化する仕組み）を有効にする設定が用意されています。

[grpc_server]
secure = true
fullchain_crt = /path/to/fullchain.crt
server_key = /path/to/server.key

secureをtrueにすると、証明書ファイル（fullchain_crt）と秘密鍵ファイル（server_key）の指定が必須になります。この2つは初期状態では値が設定されていないため、証明書を自分で用意しなければ有効化できません。

正直に言うと、ここが一番ハードルの高いところです。証明書の発行・更新の運用は、規模の小さい組織ほど後回しになりがちだと感じています。社内の閉じた検証環境だけで完結させるなら、平文のままでも大きな実害は出にくいでしょう。ただし、本番システムに投入する前、あるいは社外からアクセスできる形で公開する前には、この設定を必ず確認してください。ここは「あとで直そう」が一番危ないポイントです。

中小企業がTsurugiのような新しいOSSを扱う際の心構え

Tsurugiに限った話ではありませんが、新しいOSSは情報がまだ少なく、日本語の実践記事も限られているのが実情です。今回書いた設定項目も、私が公式の一次情報（GitHubリポジトリのドキュメント）を確認しながらまとめたもの。数年後には設定名が変わっている可能性も十分にあります。

新しい技術を安全に扱うコツは、実はそれほど複雑ではありません。

まずは閉じた検証環境で試す（社外からアクセスできない状態を保つ）
社内データを入れる前に、認証（enabled = true）を有効化する
パスワードは認証ファイル（tgctl credentials）で扱い、コードに直書きしない
本番投入・外部公開の前には、TLS（secure = true）を必ず確認する

このチェックリストは、Tsurugiに限らずどんなDBやミドルウェアにもだいたい当てはまります。逆に言えば、この4点さえ押さえていれば、新しいOSSを触ること自体を怖がる必要はありません。

とはいえ、設定項目の意味を正しく理解しないまま本番投入するのは、やはりリスクです。判断に迷うところがあれば、一人で抱え込まずに詳しい人へ聞いてみたほうが、結局は早く済むものです。

まとめ

シリーズ最終回として、Tsurugiのセキュリティ設定を見てきました。要点を整理します。

Tsurugiはデフォルトで認証なし（enabled = false）。誰でも接続できる状態が初期値
認証を有効にするにはtsurugi.iniの[authentication]セクションを設定し、認証サービス（harinoki）を起動しておく
パスワードはtgctl credentialsで作る暗号化認証ファイルを使い、コードへの直書きを避ける
本番投入・外部公開の前には、[grpc_server]のTLS設定（secure・証明書・秘密鍵）を必ず確認する

4回にわたってTsurugi（劔）を紹介してきました。国産の新しいDBを検証から実運用まで持っていくには、性能や機能だけでなく、こうした地味な設定確認が欠かせません。

▼Tsurugiシリーズ全4回
– 第1回：Tsurugi（劔）とは？国産次世代データベース入門（概要編）
– 第2回：Tsurugi（劔）を試す！インストール〜起動手順（インストール編）
– 第3回：PythonでTsurugi（劔）に接続してみる（Python接続編）
– 第4回：Tsurugi（劔）のセキュリティ設定入門：認証を有効にする（本記事）

私は普段、こうした新しいOSSの検証・PoC（実証実験）支援や、認証・暗号化まわりの設定確認を含めたセキュリティ相談を受け付けています。対象は「自社のシステムに新しい技術を入れたいが、設定を誤って事故を起こしたくない」という段階でもかまいません。気になる方は一度、無料相談へどうぞ。