次の方法で共有


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

適用対象:SQL Server on Linux

SQL Server を初めて使用する Linux ユーザーの場合は、以下のタスクにより一部のセキュリティ タスクを一通り経験できます。 これらは Linux 独自または固有のものではありませんが、さらに調べる領域について考えるヒントになります。 各例には、その領域の詳細なドキュメントのリンクが記載されています。

この記事のコード サンプルでは、AdventureWorks2025 または AdventureWorksDW2025 サンプル データベースを使用します。このサンプル データベースは、Microsoft SQL Server サンプルとコミュニティ プロジェクト ホーム ページからダウンロードできます。

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

master ステートメントを使用して データベースにログインを作成することにより、他のユーザーに SQL Server へのアクセスを許可します。 次に例を示します。

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

注意事項

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

ログインは、SQL Server に接続し、master データベースに (制限付きで) アクセスできます。 ユーザー データベースに接続するには、データベース レベルで対応するデータベース ユーザーと呼ばれる ID がログインに必要です。 ユーザーは各データベースに固有であり、アクセス権を付与するには、データベースごとに個別に作成する必要があります。 次の例では、AdventureWorks2025 データベースに移動し、CREATE USER ステートメントを使用して、Larry というログインに関連付けられた Larry という名前のユーザーを作成します。 ログインとユーザーは関連して (相互にマップされて) いますが、それらは異なるオブジェクトです。 ログインはサーバー レベルの原則です。 ユーザーは、データベース レベルのプリンシパルです。

USE AdventureWorks2022;
GO

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

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

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2022;
GO

GRANT ALTER ANY USER TO Jerry;
GO

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

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

ユーザー データベースに最初に接続するユーザーは、管理者アカウントとデータベース所有者アカウントになります。 ただし、これらのユーザーは、データベースに対するすべてのアクセス許可を使用できます。 これは、ほとんどのユーザーが持つべきものより多いアクセス許可です。

ちょうど開始するところである場合は、組み込みの固定データベース ロールを使用して、いくつかの一般的なアクセス許可のカテゴリを割り当てることができます。 たとえば、db_datareader 固定データベース ロールでは、データベース内のすべてのテーブルを読み取ることができますが、変更することはできません。 固定データベース ロールのメンバーシップを許可するには、ALTER ROLE ステートメントを使います。 次の例では、ユーザー Jerrydb_datareader 固定データベース ロールに追加します。

USE AdventureWorks2022;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

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

その後、データへのより正確なアクセス (強く推奨) を構成する準備ができたら、CREATE ROLE ステートメントを使用して、独自のユーザー定義のデータベース ロールを作成します。 次に、カスタム ロールに特定の細かいアクセス許可を割り当てます。

たとえば、次のステートメントでは、Sales という名前のデータベース ロールが作成され、Sales グループに対して Orders テーブルの行を表示、更新、削除する権限が与えられてから、ユーザー JerrySales ロールに追加されます。

CREATE ROLE Sales;

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

ALTER ROLE Sales ADD MEMBER Jerry;

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

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

行レベルのセキュリティを使用すると、クエリを実行するユーザーに基づいて、データベース内の行へのアクセスを制限することができます。 この機能は、お客様が自分のデータにのみアクセスできるようにする場合や、ユーザーが自分の部署に関連するデータにのみアクセスできるようにする場合などに役立ちます。

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

行レベルのセキュリティをテストするには、次の 2 つのユーザー アカウントを作成します。

USE AdventureWorks2022;
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;

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

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 AdventureWorks2022;
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 EmailAddress
1 ken0@adventure-works.com

変更前:

EmailAddressID EmailAddress
1 kXXX@XXXX.com

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

データベースに対する脅威の 1 つは、誰かがデータベース ファイルをハードドライブから盗み出すリスクです。 これは、侵入者がシステムへの昇格されたアクセス権を取得すること、問題のある従業員のアクション、ファイルを含むコンピューター (ラップトップなど) の盗難などによって発生する可能性があります。

Transparent Data Encryption (TDE) は、ハード ドライブに格納されているデータ ファイルを暗号化します。 SQL Server データベース エンジンの master データベースには暗号化キーがあり、データベース エンジンがデータを操作できます。 このキーへのアクセス権がなければ、データベース ファイルを読み取ることができません。 上級管理者は、キーの管理、バックアップ、再作成を行うことができます。そのため、データベースを移動することはできますが、選ばれたメンバーのみが行えます。 TDE を構成すると、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 AdventureWorks2022;
GO

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

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION ON;

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

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION OFF;

暗号化および暗号化解除の操作は、SQL Server によってバックグラウンド スレッドでスケジュールされます。 これらの操作の状態は、この後の記事に示すカタログ ビューおよび動的管理ビューを使用して確認できます。

警告

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

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

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

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

警告

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

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

USE master;
GO

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

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

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