北原です。 今回は、Windows OSを守るセキュリティ機能の中でも重要な役割を担う、アクセス制御に関する話題を解説します。
UnixやLinuxでは「Everything is a file」と言われていますが、Windows OSではファイルやプロセスをはじめとする全てのものがオブジェクトとして管理されており、それぞれが ACL（Access Control List：アクセス制御リスト） によりアクセス制御されています。 ACLは、アカウントに与えているアクセス権限を個別に定義した ACE（Access Control Entry：アクセス制御エントリ） と呼ばれる情報のリストです。 例えば、Windows OSでファイルのプロパティを開くと、以下の図のようにACLが視覚的に確認できます。
ファイルやディレクトリなどでは、Windows OS標準の機能でこのように視覚的にACLが確認できますが、オブジェクトの種類によってはそうではありません。 Windows OSのACLは、Security Descriptor（セキュリティ記述子） と呼ばれる一定の書式に従ったバイナリデータとして管理されているため、そのままでは人間にとっての可読性が高くありません。 そこで、Security Descriptorを定義するバイナリデータと等価な情報を、人間にとって可読性がある状態で表現するために、SDDL（Security Descriptor Definition Language：セキュリティ記述子定義言語） という文字列が定義されていますが、癖が強いため解読に慣れるのはやや手間です。
本記事では、Windows OSでのアクセス制御設定の効率的な管理や調査を助けるために、SDDLの読み方を中心に、以下の内容を解説します。
SDDL解読のための基礎知識
SDDL自体を解説する前に、まずは必要最低限の基礎知識から解説します。
Security Identifier
Windows OSでは、全てのアカウントは SID（Security Identifier：セキュリティ識別子） と呼ばれるバイナリデータで管理されています。
例えば、Windows OS上でコマンドプロンプト（cmd.exe）やPowerShell（powershell.exe）を起動して wmic.exe を実行すると、以下のようにOSに登録されているユーザアカウントのSIDが確認できます。
C:\>wmic.exe useraccount get name,sid Name SID admin S-1-5-21-2659926013-4203293582-4033841475-500 DefaultAccount S-1-5-21-2659926013-4203293582-4033841475-503 Guest S-1-5-21-2659926013-4203293582-4033841475-501 recovery S-1-5-21-2659926013-4203293582-4033841475-1001 WDAGUtilityAccount S-1-5-21-2659926013-4203293582-4033841475-504 Administrator S-1-5-21-3654360273-254804765-2004310818-500 Guest S-1-5-21-3654360273-254804765-2004310818-501 krbtgt S-1-5-21-3654360273-254804765-2004310818-502 david S-1-5-21-3654360273-254804765-2004310818-1104 jeff S-1-5-21-3654360273-254804765-2004310818-1105 sqlsvc S-1-5-21-3654360273-254804765-2004310818-2101 caadmin S-1-5-21-3654360273-254804765-2004310818-2601
PowerShellの場合は、Get-CimInstance または Get-WmiObject コマンドレットでWMIから情報が取得できます。
Get-CimInstance コマンドレットの場合は、以下のようにアカウント名とSIDが確認できます。
PS C:\> Get-CimInstance -ClassName Win32_UserAccount | Select-Object -Property name,sid name sid ---- --- admin S-1-5-21-2659926013-4203293582-4033841475-500 DefaultAccount S-1-5-21-2659926013-4203293582-4033841475-503 Guest S-1-5-21-2659926013-4203293582-4033841475-501 recovery S-1-5-21-2659926013-4203293582-4033841475-1001 WDAGUtilityAccount S-1-5-21-2659926013-4203293582-4033841475-504 Administrator S-1-5-21-3654360273-254804765-2004310818-500 Guest S-1-5-21-3654360273-254804765-2004310818-501 krbtgt S-1-5-21-3654360273-254804765-2004310818-502 david S-1-5-21-3654360273-254804765-2004310818-1104 jeff S-1-5-21-3654360273-254804765-2004310818-1105 sqlsvc S-1-5-21-3654360273-254804765-2004310818-2101 caadmin S-1-5-21-3654360273-254804765-2004310818-2601
S-1- で始まる文字列が、SIDのバイナリデータを文字列として表現したものです。
例として S-1-5-32-544 というSID文字列を用います。
SID文字列を - で区切った場合、それぞれ以下のような意味を持ちます。
S- SID文字列であることを示しています1- SIDのリビジョンレベル（書式のバージョンという認識で問題ありません）を表しています。本記事の執筆時点では必ず1です5- 識別子機関（アカウントの登録先くらいの認識で問題ありません）の値を示しています
アカウント名ではなくSIDによりアカウントを管理することで、アカウントの名前が変更されてもWindows OSは一意にアカウントを識別できるという仕組みです。 本記事ではあまり詳しくは触れませんが、SIDはOS内部ではバイナリデータとして処理されており、以下のSID構造体で定義されています。
typedef struct _SID {
BYTE Revision;
BYTE SubAuthorityCount;
SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
#if ...
DWORD *SubAuthority[];
#else
DWORD SubAuthority[ANYSIZE_ARRAY];
#endif
} SID, *PISID;
Security Descriptor
Security Descriptorはオブジェクトのセキュリティ設定を定義するバイナリデータであり、その書式は以下の SECURITY_DESCRIPTOR 構造体に従います（実際には、状況に応じて定義が少し異なる構造体が用いられますが、初心者にはややこしい話なので本記事では割愛します）。
typedef struct _SECURITY_DESCRIPTOR {
BYTE Revision;
BYTE Sbz1;
SECURITY_DESCRIPTOR_CONTROL Control;
PSID Owner;
PSID Group;
PACL Sacl;
PACL Dacl;
} SECURITY_DESCRIPTOR, *PISECURITY_DESCRIPTOR;
Revision はSecurity Descriptorの書式バージョンを示す1 byteの値であり、基本的には 1 です。
Sbz1 は、構造体データの大きさを調整するための1 byteの値であり、0 が設定されます。
Control は2 byte（16 bit）のフラグ値であり、自身の構造体に定義されている情報などを示す値が設定されます。
アクセス制御は、Owner、Group、Sacl、Dacl の4つの値で定義されます。
Security Descriptorのバイナリデータの概要を図示化すると、以下のようになります。
Owner には、オブジェクトの所有者アカウントを示すSIDのバイナリデータが保存されているメモリアドレスの値が設定されます。
オブジェクトの所有者アカウントは、オブジェクトに対して全ての操作が可能であるため重要です。
Group には、グループアカウントのを示すSIDのバイナリデータが保存されているメモリアドレスの値が設定され、そのグループアカウントはプライマリグループと呼ばれています。
プライマリグループはオブジェクトの作成時に設定される情報ですが、基本的には使用されない情報であるため、とりあえずは気にしなくて問題ありません。
Sacl には、SACL（System Access Control List）と呼ばれるACLのバイナリデータが格納されているメモリアドレスの値が設定されます。
SACLは、Windows OS上での監視設定の情報が定義されるACLです。
記事の趣旨とは異なるため、本記事では触れません。
最後に定義されている Dacl には、DACL（Discretionary Access Control List）と呼ばれるACLのバイナリデータが格納されているメモリアドレスの値が設定されます。
オブジェクトの操作に関するアクセス制御設定は、DACLの定義に従うため、Windows OSのセキュリティに携わる上で最も触れる機会が多いのがDACLでしょう。
本記事では、このDACLを中心に解説していきます。
Access Mask
アクセス権限はAccess Maskと呼ばれる32 bitの値で表現されており、各ビットに意味があります。 32 bitのうちの上位16 bitは全てのオブジェクトでの使用が想定されているアクセス権限を示しており、下位16 bitは管理対象のオブジェクトに固有なアクセス権限を管理するために用いられます。 以下のような構成になっています。
上位16 bitのうち、最上位の4 bit（0xF0000000）の部分は Generic Right（汎用権限） と呼ばれています。
UNIX系OSでいうRead/Write/Executeに対応する権限を示すフラグ値であり、それぞれ以下の表のような意味を持ちます。
| 権限名 | Access Mask | 概要 |
|---|---|---|
| GENERIC_READ | 0x80000000 |
オブジェクトに対する読み取り権限 |
| GENERIC_WRITE | 0x40000000 |
オブジェクトに対する書き込み権限 |
| GENERIC_EXECUTE | 0x20000000 |
オブジェクトに対する実行および調査権限 |
| GENERIC_ALL | 0x10000000 |
オブジェクトに対する読み取り、書き込み、実行権限 |
上位16 bitのうち、下位5 bit（0x001F0000）の部分は Standard Right（標準権限） と呼ばれており、それぞれ以下の表のような意味を持ちます。
| 権限名 | Access Mask | 概要 |
|---|---|---|
| SYNCHRONIZE | 0x00100000 |
オブジェクトからの同期シグナルを待機する権限 |
| WRITE_OWNER | 0x00080000 |
オブジェクトの所有者アカウントを変更する権限 |
| WRITE_DAC | 0x00040000 |
オブジェクトのセキュリティ情報を書き込む権限 |
| READ_CONTROL | 0x00020000 |
オブジェクトのセキュリティ情報を読み取る権限 |
| DELETE | 0x00010000 |
オブジェクトを削除する権限 |
上位16 bitのうち、10 bit目と9 bit目（0x02000000 と 0x01000000）の2 bitは、Windows APIでアクセス権限を要求する際に用いる特別なフラグ値です。
| 権限名 | Access Mask | 概要 |
|---|---|---|
| MAXIMUM_ALLOWED | 0x02000000 |
可能な限りの権限を要求していることを示すフラグ値 |
| ACCESS_SYSTEM_SECURITY | 0x01000000 |
オブジェクトの監査設定情報（SACL）を読み取る権限 |
MAXIMUM_ALLOWEDは、Windows APIでオブジェクトに対するアクセス権限を取得する際に、可能な限りの高い権限を要求したい場合に使用するフラグ値です。 ただし、MAXIMUM_ALLOWEDを指定してWindows APIを指定する場合は実行権限によって動作が大きく異なります。 本記事の趣旨からは逸れるため詳しくは解説しませんが、システムプログラミングの観点では、必要な動作を実行するために必要なアクセス権限をしっかり把握してアクセス権限を要求し、MAXIMUM_ALLOWEDは使わない方が無難です。
Access Maskの上位16 bitのその他の部分は定義されておらず、Windows OSでは使用されていません。 下位16 bitの値に関しては、オブジェクトによってそれぞれ意味が異なります。 例えば、プロセスのアクセス権を示すAccess Maskの値は、Microsoft公式文書のOpenProcess APIなどの文書にリンクが記載されている「セキュリティとアクセス権の処理」に掲載されています。 また、アクセス権限を要求するWindows APIの個別の文書にも、各オブジェクトに適用される下位16 bitのAccess Maskの値の意味が掲載されています。
レジストリやファイルの場合は、一つの権限を表現するために複数のビットが用いられます。 ファイルの場合は以下の表の通りです。
| 権限名 | Access Mask | 概要 |
|---|---|---|
| FILE_GENERIC_ALL | 0x001F01FF |
ファイルに対する全権限 |
| FILE_GENERIC_READ | 0x00120089 |
ファイルの読み取り権限 |
| FILE_GENERIC_WRITE | 0x00100116 |
ファイルの書き込み権限 |
| FILE_GENERIC_EXECUTE | 0x001000A0 |
ファイルの実行権限 |
レジストリの場合は以下の表の通りです。
| 権限名 | Access Mask | 概要 |
|---|---|---|
| KEY_ALL_ACCESS | 0x000F003F |
レジストリに対する全権限 |
| KEY_READ | 0x00020019 |
レジストリの読み取り権限 |
| KEY_WRITE | 0x00020006 |
レジストリの書き込み権限 |
| KEY_EXECUTE | 0x00020019 |
名前としては存在しますが、値自体はKEY_READと同じであるため、KEY_READと同一の権限 |
ACLとACE
ACLは、アカウントに対するアクセス権限を定義した個別のACEを、リストとしてまとめた構造体です。 ACLのバイナリデータの先頭部分は、以下のACL構造体で定義されており、このACL構造体のデータに連続する形でACEを定義する構造体のデータが配置されます。
typedef struct _ACL {
UCHAR AclRevision;
UCHAR Sbz1;
USHORT AclSize;
USHORT AceCount;
USHORT Sbz2;
} ACL;
AclRevision にはACLの形式を示す識別番号が設定され、多くの場合は 2 か 4 が設定されます。
Sbz1 はデータの整列に用いられるパディングであり、0 が設定されます。
AclSize は、名前が示す通り、ACLを定義する構造体と続く全てのACEを定義する構造体のデータ長を合わせたバイナリデータのサイズが設定され、ACEを定義する構造体の数（エントリ数）は AceCount に設定された数で指定されます。
ACEを定義する構造体はやや複雑です。
本記事で全てを解説するのは困難であるため、要点だけ触れます。
まず、ACEを定義する構造体の先頭には、以下のACE_HEADER構造体により、ACEの種類（AceType）、性質（AceFlags）、データサイズ（AceSize）を示します。
typedef struct _ACE_HEADER {
BYTE AceType;
BYTE AceFlags;
WORD AceSize;
} ACE_HEADER;
AceType に指定された値によって、ACEを定義する構造体が何なのかが判断できる仕組みです。
最もよく眼にする AceType の値はACCESS_ALLOWED_ACE_TYPE（0）でしょう。
ACCESS_ALLOWED_ACE_TYPEの場合は、ACE_HEADER構造体を含むACEを定義する構造体んデータは、以下のACCESS_ALLOWED_ACE構造体の定義に従います。
typedef struct _ACCESS_ALLOWED_ACE {
ACE_HEADER Header;
ACCESS_MASK Mask;
DWORD SidStart;
} ACCESS_ALLOWED_ACE;
Header の部分の、先述のACE_HEADER構造体が配置されており、それに続けてAccess Maskによりアクセス権限を示す Mask が定義されます。
SidStart は、初見だとややわかりにくいですが、擬似的な構造体メンバーであり、この部分からアカウントの情報を示すSIDのバイナリデータが配置されます（つまり実際に配置されるデータの型はDWORDではなくSID構造体そのものです）。
ACE関連の他の構造体について興味がある場合は、Microsoft公式文書のACE_HEADER構造体のページを参照してください。
続けて、ACE_HEADER構造体の AceFlags ですが、この部分には先述の通りACEの性質を示すフラグ値が設定されます。
入門記事としてはやや難しい話であるため、本記事では詳細には触れませんが、Active Directoryで管理するオブジェクトの場合だと、ACE情報が他のオブジェクトからの継承により作成されたことを示すフラグが設定される場合があります。
例えば、ドメイングループに所属しているユーザアカウントのあるACEが、所属しているグループのACEの引き継ぎにより作成された場合です。
SDDLの取得と解読の方法
ここまでで解説してきたACLやACEのバイナリデータの定義は、システムプログラミングに取り組む開発者などにとっては必要ですが、そうでない人にとっては難解です。 そこで、より幅広い利用者がACLやACEを、コマンドプロンプトなどで簡単に確認できるように、SDDL文字列というものが定義されています。 SDDLは、Security Descriptorの情報を人間にとって可読な形式で表示するための言語ですが、やや癖が強いため、解読するには知識が必要です。 SDDLが解読できると、コマンドラインで手軽にACLの設定が確認できるため、取得と解読の方法を身に付けておくと調査が便利になります。
ACL情報の取得
PowerShellには、ACLを確認するための Get-Acl というコマンドレットが実装されています。
-Path パラメータに、ACLを確認したいオブジェクトのパスを指定します。
例えば、C:\ に設定されているACLを確認したい場合は、以下のように実行します。
PS C:\> Get-Acl -Path C:\ | Format-List
Path : Microsoft.PowerShell.Core\FileSystem::C:\
Owner : NT SERVICE\TrustedInstaller
Group : NT AUTHORITY\SYSTEM
Access : NT AUTHORITY\Authenticated Users Allow AppendData
NT AUTHORITY\Authenticated Users Allow -536805376
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Administrators Allow FullControl
BUILTIN\Users Allow ReadAndExecute, Synchronize
Audit :
Sddl : O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:SYD:PAI(A;;LC;;;AU)(A;OICIIO;SDGXGWGR;;;AU)(
A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)
Owner、Group、Access、Audit がそれぞれSecurity Descriptorの Owner、Group、Dacl、Sacl に対応しています。
SACLに対応する Audit の値が空ですが、この場合はSACL自体が設定されていないか、権限が不足しているためです。
SACLを確認したい場合は SeSecurityPrivilege 特権が必要であるため、管理者権限で調査する必要があります。
SeSecurityPrivilege 特権が使用できる状態で確認しても Audit の値が空であるならば、SACLが設定されていないと言えます。
Active Directoryのオブジェクトに設定されているACLを調べたい場合は、少し手間が必要です。
例として、contoso.local というドメインで、CL01 という端末のACLを確認する場合を示します。
まずはActive Directoryのドメインのドメインコントローラにログオンして、PowerShellを起動し、ActiveDirectory モジュールをインポートします。
Import-Module ActiveDirectory
続けて、Active Directoryに登録されている CL01 に対応するオブジェクトのパスを調べます。
ActiveDirectory モジュールの Get-ADComputer コマンドレットを用いる場合は、以下のようにオブジェクトのパスが取得できます。
PS C:\> $dn = (Get-ADComputer -Identity cl01).distinguishedname PS C:\> $objPath = "AD:\$($dn)" PS C:\> $objPath AD:\CN=CL01,CN=Computers,DC=contoso,DC=local
以上の例の場合は、AD:\CN=CL01,CN=Computers,DC=contoso,DC=local が CL01 に対応するActive Directoryオブジェクトのパスです。
あとはファイルなどの場合と同様に、Get-Acl コマンドレットを実行するだけです。
PS C:\> Get-Acl -Path $objPath | Format-List
Path : Microsoft.ActiveDirectory.Management.dll\ActiveDirectory:://RootDSE/CN=CL01,CN=Computers,DC=contoso,DC=local
Owner : CONTOSO\Domain Admins
Group : CONTOSO\Domain Admins
Access : NT AUTHORITY\SELF Allow
NT AUTHORITY\Authenticated Users Allow
NT AUTHORITY\SYSTEM Allow
BUILTIN\Account Operators Allow
CONTOSO\Domain Admins Allow
Everyone Allow
NT AUTHORITY\SELF Allow
NT AUTHORITY\SELF Allow
NT AUTHORITY\SELF Allow
BUILTIN\Print Operators Allow
BUILTIN\Windows Authorization Access Group Allow
CONTOSO\Domain Admins Allow
CONTOSO\Domain Admins Allow
CONTOSO\Domain Admins Allow
CONTOSO\Domain Admins Allow
CONTOSO\Domain Admins Allow
CONTOSO\Domain Admins Allow
CONTOSO\Domain Admins Allow
CONTOSO\Cert Publishers Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
CONTOSO\Key Admins Allow
CONTOSO\Enterprise Key Admins Allow
CONTOSO\Domain Admins Allow
CREATOR OWNER Allow
NT AUTHORITY\SELF Allow
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow
NT AUTHORITY\SELF Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
NT AUTHORITY\SELF Allow
NT AUTHORITY\SELF Allow
CONTOSO\Enterprise Admins Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Administrators Allow
Audit :
Sddl : O:DAG:DAD:AI(A;;CCDC;;;PS)(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO
;;;AO)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RPWP;77b5b886-
944a-11d1-aebd-0000f80367c1;;PS)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)(OA;;SW;72e39547-7b18-11d1-ad
ef-00c04fd8d5cd;;PS)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d
456d2;;S-1-5-32-560)(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;DA)(OA;;
WP;4c164200-20c0-11d0-a768-00aa006e0529;;DA)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;DA)(OA;;SW;72e39547-
7b18-11d1-adef-00c04fd8d5cd;;DA)(OA;;WP;3e0abfd0-126a-11d0-a060-00aa006c33ed;bf967a86-0de6-11d0-a285-00aa00304
9e2;DA)(OA;;WP;bf967950-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;DA)(OA;;WP;5f202010-7
9a5-11d0-9020-00c04fc2d4cf;bf967a86-0de6-11d0-a285-00aa003049e2;DA)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa00304
9e2;;CA)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;
RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;5f202010-79a5-11
d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4c
f;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45b
c-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2
;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5
9ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b
422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf
967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIID;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;S-1-5-21-3654360273-
254804765-2004310818-526)(OA;CIID;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;S-1-5-21-3654360273-254804765-200
4310818-527)(OA;ID;SW;9b026da6-0d3c-465c-8bee-5199d7165cba;;DA)(OA;CIIOID;SW;9b026da6-0d3c-465c-8bee-5199d7165
cba;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;CIID;SW;9b026da6-0d3c-465c-8bee-5199d7165cba;bf967a86-0de6-11d
0-a285-00aa003049e2;PS)(OA;CIID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;E
D)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c
69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;CIID;WP;ea1b7b93-5e48-46d5-bc6c-
4df4fda78a35;bf967a86-0de6-11d0-a285-00aa003049e2;PS)(OA;CIIOID;LCRPLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28
;RU)(OA;CIIOID;LCRPLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;LCRPLORC;;bf967aba-0de6-11d0-a285-
00aa003049e2;RU)(OA;OICIID;RPWP;3f78c3e5-f79a-46bd-a0b8-9d18116ddc79;;PS)(OA;CIID;RPWPCR;91e647de-d96f-4b70-95
57-d63ff4f3ccd8;;PS)(A;CIID;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3654360273-254804765-2004310818-519)(A;CIID;
LC;;;RU)(A;CIID;CCLCSWRPWPLOCRSDRCWDWO;;;BA)
ファイルの場合と比較すると、かなり複雑なSDDL文字列が確認できます。
DACLを示す Access の値に CONTOSO\Domain Admins Allow などの重複した行が目立ちますが、これはActive Directoryに固有のアクセス権限を正確に表現できていないためです。
一方で、SDDLはオブジェクトに設定されたSecurity Descriptorを正確に表現しているため、この例の場合はSDDLを解読しなければ厳密なDACLは分かりません。
本記事では、以上の2つのSDDLを例に用いて、SDDL文字列の解読方法を解説します。
SDDL文字列の解読
ルートディレクトリから取得したSDDL文字列の例
まずは、前節で最初に示した以下のSDDLを例に解説します。
O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:SYD:PAI(A;;LC;;;AU)(A;OICIIO;SDGXGWGR;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)
このSDDLがSecurity Descriptorの情報と等価な情報を表現する文字列であり、それぞれの要素が Owner、Group、Sacl、Dacl の情報に対応しているわけですが、初見だとどこで区切れば良いのか分かりにくいです。
SDDLでは、Owner 情報は O:、Group 情報は G:、Sacl 情報は S:、Dacl 情報は D: で始まります。
つまり、例示しているSDDLを各情報毎に改行すると以下のようになります（Sacl は定義されていません）。
// Owner O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 // Group G:SY // Dacl D:PAI(A;;LC;;;AU)(A;OICIIO;SDGXGWGR;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)
SECURITY_DESCRIPTOR 構造体についての解説を踏まえると、Owner 情報と Group 情報にはアカウントのSID情報が指定されるため、: に続く文字列はアカウントを示しています。
Owner 情報に設定されているアカウントは、S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 というSID文字列として表示されていますが、これは NT SERVICE\TrustedInstaller と呼ばれるWindows OSでは特別な意味を持つ特権アカウントのSIDです。
つまり、O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 というSDDL文字列は「このオブジェクトの所有者アカウントは NT SERVICE\TrustedInstaller である」という情報を表現しています。
では、G: に続く SY は何を示しているのでしょうか？
SDDLでは、Windows OSにデフォルトで共通して存在する一部のアカウントは、事前に定義されたアルファベット2文字の語句で表現されます。
事前に定義されている代表的なアカウントを以下の表に示します。
| SDDL文字列 | アカウント名 |
|---|---|
AN |
NT AUTHORITY\ANONYMOUS LOGON |
AU |
NT AUTHORITY\Authenticated Users |
BA |
BUILTIN\Administrators |
BG |
BUILTIN\Guests |
BU |
BUILTIN\Users |
CO |
CREATOR OWNER |
DA |
Domain Admins |
DG |
Guest（Active Directoryドメイン用） |
DU |
Domain Users |
EA |
Enterprise Admins |
WD |
Everyone |
IU |
NT AUTHORITY\INTERACTIVE |
LA |
ビルトイン管理者 |
LG |
Guest（ローカル端末用） |
LS |
NT AUTHORITY\LOCAL SERVICE |
SY |
NT AUTHORITY\SYSTEM |
NU |
NT AUTHORITY\NETWORK |
NS |
NT AUTHORITY\NETWORK SERVICE |
PU |
BUILTIN\Power Users |
RD |
BUILTIN\Remote Desktop Users |
SY は NT AUTHORITY\SYSTEM です。
よって、G:SY というSDDL文字列は「このオブジェクトのプライマリグループアカウントは NT AUTHORITY\SYSTEM である」という情報を示しています。
Sacl と Dacl はACLの定義であるため、SDDL文字列の書式は同じです。
書式は以下に従います。
<DまたはS>:(<ACE文字列1>)(<ACE文字列2>)......(<ACE文字列N>)
例示しているSDDL文字列には、D: と (A;;LC;;;AU) の間に PAI という文字列が存在していますが、この文字列についてはあまり重要でないため無視して問題ありません。
ACE文字列に関しては、以下の書式に従います。
<ACEタイプ>;<ACEフラグ>;<アクセス権限>;<オブジェクトのGUID>;<継承オブジェクトのGUID>;<アカウント>
ACEタイプのフィールドには、許可リストか拒否リストかを示す文字列が設定され、A（Allowd、許可）か D（Denied、拒否）のどちらかです。
ほとんどの場合は許可リスト形式のACEでACLを構築するため、A が指定されます。
ACEフラグのフィールドには、ACEの性質を示す情報が設定されます。 本記事が意図している範囲を超える話題であるため、詳しい解説は割愛します。
アクセス権限のフィールドには、権限のAccess Mask情報が設定されます。 Generic Right、Standard Rightをはじめとする適用範囲が広い権限については、以下の表に示す事前に定義されたアルファベット2文字の語句で表現されます。 これらの文字列で表現できない場合は、16進数の形式でAccess Maskが表示されます。
| SDDL文字列 | 権限名 |
|---|---|
GA |
GENERIC_ALL |
GR |
GENERIC_READ |
GW |
GENERIC_WRITE |
GX |
GENERIC_EXECUTE |
RC |
READ_CONTROL |
SD |
DELETE |
WD |
WRITE_DAC |
WO |
WRITE_OWNER |
RP |
READ_PROPERTY |
WP |
WRITE_PROPERTY |
CC |
CREATE_CHILD |
DC |
DELETE_CHILD |
LC |
LIST_CHILDREN |
SW |
SELF_WRITE |
LO |
LIST_OBJECT |
DT |
DELETE_TREE |
CR |
CONTROL_ACCESS |
また、Active DirectoryのオブジェクトのACEの場合は、アクセス権限を示す文字列として以下の文字列が定義されています。
| SDDL文字列 | 権限名 | 概要 |
|---|---|---|
RP |
READ_PROPERTY | 属性値の読み取り権限 |
WP |
WRITE_PROPERTY | 属性値の書き込み権限 |
CC |
CREATE_CHILD | 子オブジェクトの作成権限 |
DC |
DELETE_CHILD | 子オブジェクトの削除権限 |
LC |
LIST_CHILDREN | 子オブジェクトの列挙権限 |
SW |
SELF_WRITE | 書き込み権限を制御するための権限 |
LO |
LIST_OBJECT | オブジェクト情報の列挙権限 |
DT |
DELETE_TREE | 子オブジェクトの一括削除権限 |
CR |
CONTROL_ACCESS | 拡張アクセス権によって制御される操作の実行権限 |
ファイルやプロセスなどの一般的なオブジェクトは、32 bitのAccess Maskで十分に権限が表現できますが、Active Directoryのオブジェクトは、例えば「ユーザアカウントのパスワードを変更する権限」や「グループにユーザアカウントを追加する権限」などのような、32 bitのAccess Maskでは表現できない権限を処理できなければなりません。 以下のスクリーンショットは、Active Directoryのオブジェクトの設定画面を示しています。 32個では収まらない数の権限が定義されていることが確認できるでしょう。
オブジェクトのGUIDと継承オブジェクトのGUIDのフィールドに関しては、あまり深く解説しませんが、Access Maskだけでは表現できない特殊な権限などを示すGUIDが設定されます。 最後のアカウント情報のフィールドは、所有者情報などと同様に、アカウントを示す事前定義された文字列かSID文字列が設定されます。
では、ここまでの内容を踏まえて、(A;;LC;;;AU)(A;OICIIO;SDGXGWGR;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU) というSDDL文字列を解読してみましょう。
まず (A;;LC;;;AU) については以下の表のように解読できます。
| フィールド名 | 設定値 |
|---|---|
| ACEタイプ | 許可リスト（A） |
| ACEフラグ | - |
| アクセス権限 | LIST_CHILDREN（LC） |
| オブジェクトのGUID | - |
| 継承オブジェクトのGUID | - |
| アカウント | NT AUTHORITY\Authenticated Users（AU） |
例に用いているSDDL文字列は C:\ ディレクトリに設定されているSecurity Descriptorを示すものでした。
つまり、このACE文字列は「端末のログオンに成功した全てのアカウント（NT AUTHORITY\Authenticated Users）は、C:\ 直下のオブジェクトを列挙できる」という意味になります。
同じ要領で解読すると、(A;OICIIO;SDGXGWGR;;;AU) というACE文字列は「NT AUTHORITY\Authenticated Users にDELETE、GENERIC_EXECUTE、GENERIC_WRITE、GENERIC_READ権限を許可するACE」であると分かります。
最後のACEはアクセス権限が 0x1200a9 と表示されているため、事前に定義されている文字列では表現ができないアクセス権限が設定されています。
この場合は、SDDL文字列の取得もとであるオブジェクトに対応するAccess Maskの意味を調べなければなりません。
例に用いているSDDL文字列は C:\ ディレクトリのものであるため、ディレクトリからアクセス権限を取得するために用いるWindows APIであるCreateFile APIのMicrosoft公式文書を調べてみましょう。
調べてみると、FILE_GENERIC_READ（0x00120089）とFILE_EXECUTE （0x00000020）の値をOR演算すると0x1200a9 であるため、0x1200a9 というAccess Maskはファイルの読み取り権限と実行権限を示しているとわかります。
Active Directoryから取得したSDDL文字列の例
続けて、Active Directoryから取得した以下のSDDL文字列について解説します。
O:DAG:DAD:AI(A;;CCDC;;;PS)(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AO)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;DA)(OA;;WP;4c164200-20c0-11d0-a768-00aa006e0529;;DA)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;DA)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;DA)(OA;;WP;3e0abfd0-126a-11d0-a060-00aa006c33ed;bf967a86-0de6-11d0-a285-00aa003049e2;DA)(OA;;WP;bf967950-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;DA)(OA;;WP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a86-0de6-11d0-a285-00aa003049e2;DA)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIID;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;S-1-5-21-3654360273-254804765-2004310818-526)(OA;CIID;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;S-1-5-21-3654360273-254804765-2004310818-527)(OA;ID;SW;9b026da6-0d3c-465c-8bee-5199d7165cba;;DA)(OA;CIIOID;SW;9b026da6-0d3c-465c-8bee-5199d7165cba;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;CIID;SW;9b026da6-0d3c-465c-8bee-5199d7165cba;bf967a86-0de6-11d0-a285-00aa003049e2;PS)(OA;CIID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;CIID;WP;ea1b7b93-5e48-46d5-bc6c-4df4fda78a35;bf967a86-0de6-11d0-a285-00aa003049e2;PS)(OA;CIIOID;LCRPLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;LCRPLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;LCRPLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;OICIID;RPWP;3f78c3e5-f79a-46bd-a0b8-9d18116ddc79;;PS)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(A;CIID;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3654360273-254804765-2004310818-519)(A;CIID;LC;;;RU)(A;CIID;CCLCSWRPWPLOCRSDRCWDWO;;;BA)
解読方法については C:\ から取得したSDDL文字列の例と大差ないため、違う部分だけ解説します。
例として (OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;DA) を取り上げます。
まずはACEタイプを示す OA です。
ACEタイプについては、Microsoft公式文書のACE文字列のページの「フィールド」の項目から確認できます。
文書によると、SDDL_OBJECT_ACCESS_ALLOWEDというACEタイプを示す文字列ですが、要するに「Active Directoryのオブジェクトについてのアクセス許可エントリである」ということです。
アクセス権限のフィールドには WP が設定されています。
これは先述の通り、Write Property、つまりは属性値の書き込み権限を示しています。
何の属性値かというのは、次のフィールドに設定されているGUIDから判断できます。
続けて、先ほどの C:\ の例とは異なり、オブジェクトのGUIDと継承オブジェクトのGUIDのフィールドが埋まっています。
この場合は、これらのGUIDが何を意味するのかを調べなければなりません。
GUIDを抜き出して、Googleなどの検索エンジンでそのまま検索に掛けると、Microsoftの公式文書などの情報が確認できます。
Active Directoryに関連するオブジェクトであれば、Microsoft公式文書のクラス (AD スキーマ)のページから、オブジェクトを示すGUIDが調べられます。
| GUID | 意味 | 概要 |
|---|---|---|
| bf967953-0de6-11d0-a285-00aa003049e2 | Display-Name属性 | 表示名を設定するための属性。 |
| bf967a86-0de6-11d0-a285-00aa003049e2 | Computerオブジェクト | 適用対象のオブジェクトがComputerである。 |
最後に、アカウント情報のフィールドの DA ですが、これは先述の通り Domain Admins グループを示しています。
まとめると、この (OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;DA) というACE文字列は、「Domain Admins グループに所属するアカウントは、このACEが設定されているコンピュータアカウント（この例の場合は CL01）のオブジェクトの表示名の変更が許可されている」という意味です。
ツールによる確認例
Security DescriptorやSDDLなどについて理解できたところで、実際にアクセス権限を確認するツールの使用方法を把握しておきましょう。
icacls.exe
icacls.exeは、Microsoft Windows OSでファイルの権限を管理するために、標準インストールされているコマンドラインツールです。 引数に単にファイル名を指定すれば、以下のようにアクセス権限（DACL）が確認できます。
PS C:\> icacls.exe C:\Windows\System32\kernel32.dll
C:\Windows\System32\kernel32.dll NT SERVICE\TrustedInstaller:F
BUILTIN\Administrators:R
NT AUTHORITY\SYSTEM:R
BUILTIN\Users:R
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:R
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:R
アカウント名に続けて、: を挟んで、与えられている権限が文字列として表示されています。
これらの値の意味はicacls.exeのヘルプメッセージ（icacls.exe /? と実行）から確認できます。
以上の例の場合は、F は全権限、R は読み取り権限を示しています。
DACLをSDDL文字列として確認したい場合は、以下のように /save オプションでファイルとして出力します。
PS C:\> icacls C:\Windows\System32\kernel32.dll /save sddl-kernel32.txt processed file: C:\Windows\System32\kernel32.dll Successfully processed 1 files; Failed processing 0 files PS C:\> type .\sddl-kernel32.txt kernel32.dll D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;0x1200a9;;;BA)(A;;0x1200a9;;;SY)(A;;0x1200a9;;;BU)(A;;0x1200a9;;;AC)(A;;0x1200a9;;;S-1-15-2-2)S:AI
accesschk.exe
Microsoft Windows OSに標準インストールされているツールではありませんが、Microsoft公式の開発者向けツールであるSysinternals Suiteのaccesschk.exeでは、DACL以外のSecurity Descriptor情報が確認できます。 Sysinternals Suiteは、Microsoft公式ページの他にも、Microsoft Storeアプリ経由でもインストール可能です。
accesschk.exeの引数に単にファイル名を指定して実行した場合は、icacls.exeの場合と同様に、簡略化された形式のDACL情報が出力されます。
PS C:\> accesschk.exe C:\WIndows\System32\kernel32.dll Accesschk v6.15 - Reports effective permissions for securable objects Copyright (C) 2006-2022 Mark Russinovich Sysinternals - www.sysinternals.com C:\WIndows\System32\kernel32.dll RW NT SERVICE\TrustedInstaller R BUILTIN\Administrators R NT AUTHORITY\SYSTEM R BUILTIN\Users R APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES R APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES
-L フラグを設定すると、DACL情報のみではなく、所有者情報とSACL情報を含んだSDDL文字列が出力されます（プライマリグループ情報が出力されていないのは、実際には使用されない情報であるからと考えられます）。
PS C:\> accesschk.exe -L C:\Windows\System32\kernel32.dll Accesschk v6.15 - Reports effective permissions for securable objects Copyright (C) 2006-2022 Mark Russinovich Sysinternals - www.sysinternals.com C:\Windows\System32\kernel32.dll O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;0x1200a9;;;BA)(A;;0x1200a9;;;SY)(A;;0x1200a9;;;BU)(A;;0x1200a9;;;AC)(A;;0x1200a9;;;S-1-15-2-2)S:AI
sc.exe
sc.exeは、サービスを管理（Service Control）するための、Microsoft Windows OSに標準インストールされているコマンドラインツールです。
sdshow オプションを用いると、サービスに設定されたDACL情報（サービス制御権限）が確認できます。
以下の例は、Microsoft DefenderのサービスのDACL情報をSDDL文字列として確認した際の例です。
cmd.exeから実行する場合は sc と実行して問題ありませんが、PowerShellから実行する場合は sc が Set-Content コマンドレットにエイリアスされているため、sc.exe と実行しなければならない点に注意してください。
PS C:\> sc.exe sdshow windefend D:(A;;CCLCSWRPLOCRRC;;;BU)(A;;CCLCSWRPLOCRRC;;;SY)(A;;CCLCSWRPLOCRRC;;;BA)(A;;CCLCSWRPLOCRRC;;;IU)(A;;CCLCSWRPLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1913148863-3492339771-4165695881-2087618961-4109116736)
アクセス権限を示すフィールドの値は、サービスの場合は別の意味が設定されているため注意が必要です。
アクセス権限の意味を調べたい場合は、以上の sc.exe の最後に showrights オプションを指定します。
PS C:\> sc.exe sdshow windefend showrights D:(A;;CCLCSWRPLOCRRC;;;BU)(A;;CCLCSWRPLOCRRC;;;SY)(A;;CCLCSWRPLOCRRC;;;BA)(A;;CCLCSWRPLOCRRC;;;IU)(A;;CCLCSWRPLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1913148863-3492339771-4165695881-2087618961-4109116736) SDDL right Right value ---------- ----------- GA - GENERIC_ALL GR - GENERIC_READ GW - GENERIC_WRITE GX - GENERIC_EXECUTE RC - READ_CONTROL SD - DELETE WD - WRITE_DAC WO - WRITE_OWNER RP - SERVICE_START WP - SERVICE_STOP CC - SERVICE_QUERY_CONFIG DC - SERVICE_CHANGE_CONFIG LC - SERVICE_QUERY_STATUS SW - SERVICE_ENUMERATE_DEPENDENTS LO - SERVICE_INTERROGATE DT - SERVICE_PAUSE_CONTINUE CR - SERVICE_USER_DEFINED_CONTROL
例えば RP は、通常の場合は「属性値の読み取り権限（READ_PROPERTY）」という意味で用いられますが、サービスに関しては「サービスの起動権限（SERVICE_START）」という意味で用いられていることが確認できます。
それぞれの意味を、以下の表にまとめます。
| SDDL文字列 | サービスでの権限名 | 概要 |
|---|---|---|
RP |
SERVICE_START | サービスの開始権限 |
WP |
SERVICE_STOP | サービスの停止権限 |
CC |
SERVICE_QUERY_CONFIG | サービスの設定確認権限 |
DC |
SERVICE_CHANGE_CONFIG | サービスの設定変更権限 |
LC |
SERVICE_QUERY_STATUS | サービスの状態確認権限 |
SW |
SERVICE_ENUMERATE_DEPENDENTS | 対象サービスに依存するサービス情報の列挙権限 |
LO |
SERVICE_INTERROGATE | サービスへの状態の報告権限 |
DT |
SERVICE_PAUSE_CONTINUE | サービスの一時停止と再開権限 |
CR |
SERVICE_USER_DEFINED_CONTROL | ユーザ定義の制御コードの指定権限 |
まとめ
Microsoft Windows OSでは、その豊富な機能のため、アクセス権限の不備が、権限昇格の脆弱性などの大きな問題につながる可能性があります。 アクセス権限をしっかり管理できる技術を身につけると、権限設定の不備を特定してMicrosoft Windows OSのセキュリティを強固なものにできます。
Security Descriptor、ACL、SDDL文字列などに関してより詳しい知識が欲しい人は、以下の文献を読むと良いでしょう。
