SQL Server on Linux のセキュリティ機能のチュートリアル

適用対象:Linux 上の SQL Server

SQL Server を初めて使用する Linux ユーザーの場合は、以下のタスクにより一部のセキュリティタスクを一通り経験できます。これらのタスクはLinuxに特有のものでもありませんが、さらに調査すべき分野のイメージを得られます。各例はその分野の詳細なドキュメントへのリンクがあります。

この記事のコードサンプルは、Azure Data SQL Samples Repository GitHub repositoryからダウンロードできるAdventureWorks2025またはAdventureWorksDW2025サンプルデータベースを使用しています。

master文でCREATE LOGINデータベースにログインを作成することで、他の人にSQL Serverへのアクセスを許可してください。例えば次が挙げられます。

CREATE LOGIN Larry
    WITH PASSWORD = '<password>';

Caution

パスワードは SQL Server の既定のパスワードポリシーに従う必要があります。既定では、パスワードの長さは少なくとも 8 文字で、大文字、小文字、10 進数の数字、記号の 4 種類のうち 3 種類を含んでいる必要があります。パスワードには最大 128 文字まで使用できます。可能な限り長く複雑なパスワードを使用してください。

ログインは、SQL Server に接続し、master データベースに (制限付きで) アクセスできます。ユーザーデータベースに接続するには、データベースレベルで対応するデータベースユーザーと呼ばれる ID がログインに必要です。ユーザーは各データベースごとに固有のため、アクセスを許可するには各データベース内で別々に作成する必要があります。

以下の例では、AdventureWorks2025 データベースに切り替え、次に CREATE USER ステートメントを使用して、Larry という名前のログインに対応付けられた Larry という名前のユーザーを作成します。ログインとユーザーは関連しています(互いにマッピングされています)が、異なるオブジェクトです。ログインはサーバーレベルの原則です。ユーザーは、データベースレベルのプリンシパルです。

USE AdventureWorks2025;
GO

CREATE USER Larry;
GO

SQL Server の管理者アカウントでは、任意のデータベースに接続し、データベースにさらに多くのログインとユーザーを作成できます。
データベースを作成すると、あなたはデータベースの所有者となり、そのデータベースに接続できます。データベース所有者は、さらにユーザーを作成できます。

後で、他のログインに ALTER ANY LOGIN 権限を付与することで、それらがさらにログインを作成できるように許可できます。データベース内では、他のユーザーに ALTER ANY USER アクセス許可を付与することで、より多くのユーザーを作成することを承認できます。例えば次が挙げられます。

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Jerry;
GO

これでログイン Larry はさらに多くのログインを作成でき、ユーザー Jerry もさらに多くのユーザーを作成できるようになりました。

最小限の特権でアクセス権を付与

管理者やデータベース所有者は通常、ユーザーデータベースに接続する最初のユーザーです。これらのアカウントはデータベース上ですべての権限を持っています。権限が少ないタスクにはこれらのアカウントは使わないでください。

始めたばかりのときは、組み込みの 固定データベースロールで一般的な権限カテゴリを割り当てることができます。例えば、 db_datareader 固定データベースの役割はデータベース内のすべてのテーブルを読み込むことができますが、変更はできません。 ALTER ROLE ステートメントを使用して、固定データベースロールのメンバーシップを付与します。以下の例は、ユーザー Jerry を db_datareader 固定データベースの役割に追加しています。

USE AdventureWorks2025;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

固定データベースロールの一覧については、「データベースレベルのロール」をご覧ください。

後で、より正確なデータアクセスを設定する準備ができたら(強くおすすめします)、 CREATE ROLE 文でユーザー定義のデータベースロールを作成しましょう。次に、カスタムロールに特定の細かいアクセス許可を割り当てます。

例えば、以下の文は Salesというデータベースロールを作成し、 Sales グループに Orders テーブルから行を読み込み、更新し、削除する権限を与え、ユーザー Jerry を Sales ロールに追加します。

CREATE ROLE Sales;

GRANT SELECT ON OBJECT::Orders TO Sales;
GRANT UPDATE ON OBJECT::Orders TO Sales;
GRANT DELETE ON OBJECT::Orders TO Sales;

ALTER ROLE Sales ADD MEMBER Jerry;

権限システムの詳細については、「データベースエンジンの権限の概要」を参照してください。

行レベルのセキュリティを構成する

行レベルのセキュリティにより、クエリを実行するユーザーによってデータベース内の行へのアクセスを制限できます。この機能は、顧客が自分のデータにしかアクセスできないようにしたり、従業員が自分の部署のデータだけにアクセスできるようにするシナリオに役立ちます。

以下の手順では、Sales.SalesOrderHeader テーブルに対して異なる行レベルのアクセス権を持つ2人のユーザーを設定する方法を説明します。

行レベルのセキュリティをテストするために2つのユーザーアカウントを作成しましょう:

USE AdventureWorks2025;
GO

CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;

両方のユーザーに、Sales.SalesOrderHeader テーブルに対する読み取りアクセス権を付与します。

GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;

新しいスキーマと、インラインテーブル値関数を作成します。この関数は、1列の行がSalesPersonIDログインのIDと一致する場合、またはクエリを実行するユーザーがSalesPersonユーザーである場合にManager返します。

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
    SELECT 1 AS fn_securitypredicate_result
    WHERE ('SalesPerson' + CAST (@SalesPersonId AS VARCHAR (16)) = USER_NAME())
          OR (USER_NAME() = 'Manager')

テーブルで、フィルター述語およびブロック述語としてこの関数を追加するセキュリティポリシーを作成します。

CREATE SECURITY POLICY SalesFilter
    ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader,
    ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader
    WITH (STATE = ON);

以下の文を実行して、各ユーザーとして SalesOrderHeader テーブルにクエリを行ってください。 SalesPerson280 によって、それぞれの売上から 95 行だけが表示され、テーブル内のすべての行が Manager に表示されることを確認します。

EXECUTE AS USER = 'SalesPerson280';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

EXECUTE AS USER = 'Manager';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

セキュリティポリシーを変更して無効にしてください。これで、両方のユーザーがすべての行にアクセスできるようになりました。

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

動的データマスクを有効にする

動的データマスクを使用すると、特定の列を完全にまたは部分的にマスキングすることによって、アプリケーションのユーザーに機密データの公開を制限することができます。

ALTER TABLE テーブルの EmailAddress 列にマスキング関数を追加するには、Person.EmailAddress ステートメントを使用します。

USE AdventureWorks2025;
GO

ALTER TABLE Person.EmailAddress
    ALTER COLUMN EmailAddress
        ADD MASKED WITH (FUNCTION = 'email()');

テーブル上でTestUser権限を持つ新しいユーザーSELECTを作成し、マスクされたデータを閲覧するためにTestUserとしてクエリを実行します。

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT
    ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID,
       EmailAddress
FROM Person.EmailAddress;

REVERT;

マスキング関数によって、最初のレコードの電子メールアドレスが次のように変更されていることを確認します。

EmailAddressID	メールアドレス
1	`ken0@adventure-works.com`

に

EmailAddressID	メールアドレス
1	`kXXX@XXXX.com`

透過的なデータ暗号化を有効にする

攻撃者はあなたのハードドライブからデータベースファイルを盗むことができます。これは攻撃者がシステムに上位アクセス権を得た場合、従業員がファイルを持ち去った場合、あるいはファイルが保管されているコンピュータを盗まれた場合に起こり得ます。

Transparent Data Encryption (TDE) は、ハードドライブに格納されているデータファイルを暗号化します。 SQL Server データベースエンジンのmasterデータベースには暗号鍵があり、データベースエンジンがデータを操作できます。このキーへのアクセス権がなければ、データベースファイルを読み取ることができません。上位管理者はキーを管理、バックアップ、再作成できるため、選ばれた人だけがデータベースを移動できます。 TDEを有効にすると、SQL Server自動的にtempdbデータベースも暗号化されます。

データベースエンジンがデータを読み取れるため、TDEはコンピュータ管理者による不正アクセスを防いでいません。管理者は直接メモリを読み取ったり、管理者アカウントを通じてSQL Serverにアクセスすることができます。

TDE の構成

マスターキーを作成します。
マスターキーで保護された証明書を作成または取得します。
データベースの暗号化鍵を作成し、証明書で保護します
暗号化を使用するようにデータベースを設定します。

TDE を構成するには、CONTROL データベースに対する master 権限と、ユーザーデータベースに対する CONTROL 権限が必要です。通常、管理者が TDE を構成します。

以下の例は、サーバーにインストールされた「AdventureWorks2025」という証明書を使ってMyServerCertデータベースを暗号化・復号する方法を示しています。

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My Database Encryption Key Certificate';
GO

USE AdventureWorks2025;
GO

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION ON;

TDE を削除するには、次のコマンドを実行します。

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION OFF;

SQL Serverはバックグラウンドスレッドに対して暗号化および復号処理をスケジュールします。これらの操作の状況は、この記事の後半に掲載されるリストでカタログビューおよび動的管理ビューで確認できます。

Warning

データベースの暗号化鍵は、TDEが有効なデータベースのバックアップファイルも暗号化します。このため、このバックアップを復元するときには、データベース暗号化キーを保護している証明書が必要です。データベースのバックアップに加え、データ損失を防ぐためにサーバー証明書もバックアップする必要があります。証明書がもはや利用できない場合、データ損失が生じます。詳細については、「 SQL Server Certificates and Asymmetric Keys」をご覧ください。

TDE の詳細については、「Transparent Data Encryption (TDE)」を参照してください。

バックアップの暗号化の構成

SQL Serverはバックアップ作成中にデータを暗号化できます。バックアップの作成時に暗号化アルゴリズムと暗号化機能 (証明書または非対称キー) を指定することにより、暗号化されたバックアップファイルを作成することができます。

Warning

証明書や非対称鍵は常にバックアップし、できれば暗号化するバックアップファイルとは別の場所に保存してください。証明書または非対称キーがないと、バックアップを復元できず、バックアップファイルのレンダリングが使用できなくなります。

次の例では、証明書を作成し、証明書によって保護されているバックアップを作成します。

USE master;
GO

CREATE CERTIFICATE BackupEncryptCert
    WITH SUBJECT = 'Database backups';
GO

BACKUP DATABASE [AdventureWorks2025]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2025.bak'
WITH COMPRESSION,
    ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
    STATS = 10;
GO

詳細については、「バックアップの暗号化」をご覧ください。

SQL Server データベースエンジンと Azure SQL Database のセキュリティ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-14

SQL Server on Linux のセキュリティ機能のチュートリアル

ログインとデータベース ユーザーを作成する

最小限の特権でアクセス権を付与

行レベルのセキュリティを構成する

動的データ マスクを有効にする

透過的なデータ暗号化を有効にする

TDE の構成

バックアップの暗号化の構成

関連するコンテンツ

フィードバック

その他のリソース

ログインとデータベースユーザーを作成する

動的データマスクを有効にする