適用対象:Linux 上の SQL Server
SQL Server を初めて使用する Linux ユーザーの場合は、以下のタスクにより一部のセキュリティ タスクを一通り経験できます。 これらのタスクはLinuxに特有のものでもありませんが、さらに調査すべき分野のイメージを得られます。 各例はその分野の詳細なドキュメントへのリンクがあります。
この記事のコード サンプルでは、AdventureWorks2025 または AdventureWorksDW2025 サンプル データベースを使用します。このサンプル データベースは、Microsoft SQL Server サンプルとコミュニティ プロジェクト ホーム ページからダウンロードできます。
ログインとデータベース ユーザーを作成する
CREATE LOGIN文でmasterデータベースにログインを作成することで、他の人に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;
権限システムの詳細については、「データベース エンジンの権限の概要」を参照してください。
行レベルのセキュリティを構成する
行レベルのセキュリティにより 、クエリを実行するユーザーによってデータベース内の行へのアクセスを制限できます。 この機能は、顧客が自分のデータにしかアクセスできないようにしたり、従業員が自分の部署のデータだけにアクセスできるようにするシナリオに役立ちます。
以下の手順では、異なる行レベルのアクセス権を持つ2人のユーザーを設定する方法を Sales.SalesOrderHeader ていきます。
行レベルのセキュリティをテストするために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;
新しいスキーマと、インライン テーブル値関数を作成します。 この関数は、SalesPersonID列の行がSalesPersonログインのIDと一致する場合、またはクエリを実行するユーザーがManagerユーザーである場合に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 AdventureWorks2025;
GO
ALTER TABLE Person.EmailAddress
ALTER COLUMN EmailAddress
ADD MASKED WITH (FUNCTION = 'email()');
テーブル上でSELECT権限を持つ新しいユーザーTestUserを作成し、マスクされたデータを閲覧するために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 を構成します。
以下の例は、サーバーにインストールされた「MyServerCert」という証明書を使ってAdventureWorks2025データベースを暗号化・復号する方法を示しています。
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
詳細については、「バックアップの暗号化」をご覧ください。