MENU

Windowsでファイルの「セキュリティ」タブにユーザーが表示されない時の完全対処ガイド（SQL Serverの.bak対応・所有権とNTFS権限の復旧手順）

Windows

ある日、SQL Server の .bak ファイルを開こうとしたら、ファイルの「セキュリティ」タブにユーザーが何も表示されず、名前の変更も削除もできない――。この症状は NTFS のアクセス制御リスト（ACL）や所有権が崩れているときに典型的に起きます。本記事では、最短復旧から恒久対策、運用のベストプラクティスまでを実務目線で整理します。

目次

症状と背景整理（なぜ「セキュリティ」タブに誰もいないのか）

Windows のファイルやフォルダーは、NTFS ACL によってアクセス可否が決まります。ACL は「誰（SID＝セキュリティ識別子）」に「何の権限（ACE＝アクセス許可エントリ）」を与えるかの一覧です。次のような条件が重なると、セキュリティ タブからエントリが消えたように見えたり、編集ボタンが押せなかったりします。

  • バックアップを作成したアカウント（例：LocalSystem や SQL Server のサービス アカウント）が現在の PC で解決できず「不明なアカウント（Unknown Account）」に変わった。
  • ACL の継承が無効化され、かつ現在のユーザーや所属グループが DACL に含まれていない。
  • 所有者（Owner）が別の SID に設定され、現在のユーザーが編集に必要な WRITE_DAC を持っていない。
  • ドメイン離脱や SID の再発行（再インストール・別 AD など）により、ACL に紐づく SID が孤立した。

この状態でも、管理者（Administrators）権限があれば「所有権の取得（take ownership）」と「権限の再付与」で回復できます。

最短復旧フロー（まとめ表）

手順内容重要ポイント
① 管理者権限で操作開始ファイル／フォルダーを右クリック → プロパティ → セキュリティ → 編集ローカル管理者権限がないとボタンが無効化される
② 所有権を取得（必要な場合）詳細設定 → 所有者 → 変更 → 自分または Administrators を指定 → 「サブコンテナーとオブジェクトの所有者を置換」にチェック → OKSID が壊れていると編集できないため、まず所有権を取り戻す
③ ユーザー／グループを追加編集 → 追加 → 詳細設定 → 検索 → 目的のアカウント（自分・Administrators・SYSTEM など）を選択 → OK「フルコントロール」「読み取り」「書き込み」など必要な権限にチェック
④ 継承を修復（任意）フォルダー単位で 詳細設定 → 継承の有効化上位フォルダーの正常なアクセス許可を一括適用できる
⑤ コマンドライン代替策管理者 PowerShell／CMD で
takeown /f "C:\path\backup.bak"
icacls "C:\path\backup.bak" /grant Administrators:F /inheritance:e		GUI が開けない・大量ファイルを一括処理したい場合に有効

GUI（エクスプローラー）での復旧：詳解

所有者の確認と変更

  1. 対象ファイル（例：backup.bak）を右クリック → プロパティ → セキュリティ → 詳細設定。
  2. 所有者 が「不明なアカウント」や別 SID なら、右側の 変更 をクリック。
  3. ユーザー選択ダイアログで自分のユーザー名、または Administrators を指定して OK。
  4. フォルダー配下をまとめて直すなら「サブコンテナーとオブジェクトの所有者を置換」にチェック。

ポイント： 所有者になると、そのオブジェクトの DACL を変更できるようになります。まずはここを確実に押さえるのが近道です。

アクセス許可の再付与

  1. セキュリティ タブ → 編集 → 追加。
  2. 詳細設定 → 今すぐ検索 で Administrators、自分のユーザー、SYSTEM を選び、OK。
  3. 必要な権限にチェック（管理作業なら一時的に フル コントロール）。
  4. フォルダーの場合、適用先 を「このフォルダー、サブフォルダーおよびファイル」にする。

継承（Inheritance）の復活

上位フォルダーの正しい ACL を使い回したいなら、詳細設定 → 継承の有効化 を押します。既存の明示 ACE が邪魔をしているときは、明示 ACE を削除して親からの継承だけに寄せると管理が楽になります。

コマンドで一気に直す：takeown ＆ icacls 実践集

単一ファイルを復旧

REM 管理者 CMD または 管理者 PowerShell から
takeown /f "C:\Backup\backup.bak" /a
icacls "C:\Backup\backup.bak" /setowner "Administrators"
icacls "C:\Backup\backup.bak" /grant Administrators:F /grant SYSTEM:F /grant "%USERNAME%":F /inheritance:e

Tip： 環境の言語に依存しないように、組み込みグループは SID 指定も可能です。例えば Administrators は *S-1-5-32-544。

icacls "C:\Backup\backup.bak" /grant *S-1-5-32-544:F

フォルダー配下をまとめて復旧（継承あり）

takeown /f "D:\SqlBackups" /r /d Y /a
icacls "D:\SqlBackups" /setowner "Administrators" /T
icacls "D:\SqlBackups" /inheritance:e
icacls "D:\SqlBackups" /grant:r Administrators:(OI)(CI)F SYSTEM:(OI)(CI)F "BackupOperators":(OI)(CI)M /T
  • (OI)：ファイルに継承、(CI)：フォルダーに継承
  • /grant:r：既存の同一 SID の ACE を置換して上書き

未知の SID（不明なアカウント）を削除

REM まず表示して SID を把握
icacls "D:\SqlBackups\backup.bak"

REM 例：不明な SID を取り除く
icacls "D:\SqlBackups\backup.bak" /remove *S-1-5-21-9999999999-8888888888-7777777777-1234

一括削除は誤爆が怖いので、保存→確認→復元の三段構えが安全です。

icacls "D:\SqlBackups" /save "D:\acl-backup.txt" /T
REM acl-backup.txt を目視点検してから
icacls "D:\SqlBackups" /restore "D:\acl-backup.txt"

親の既定に完全リセットしたい（最終手段）

REM 子の明示 ACE をクリアし、親の既定に合わせる
icacls "D:\SqlBackups" /reset /T

注意： /reset は現在の明示 ACE を消します。必要最小限の範囲で使用してください。

PowerShell での厳密制御（スクリプト例）

単一ファイルの ACL を安全に再構成

$Path = "C:\Backup\backup.bak"
$Admin = New-Object System.Security.Principal.NTAccount("Administrators")
$Sys   = New-Object System.Security.Principal.NTAccount("SYSTEM")
$Me    = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name

# 所有者のセット

$acl = Get-Acl -Path $Path
$acl.SetOwner($Admin)
Set-Acl -Path $Path -AclObject $acl

# 明示 ACE を再構築

$ruleAdmin = New-Object System.Security.AccessControl.FileSystemAccessRule($Admin,"FullControl","ContainerInherit,ObjectInherit","None","Allow")
$ruleSys   = New-Object System.Security.AccessControl.FileSystemAccessRule($Sys,"FullControl","ContainerInherit,ObjectInherit","None","Allow")
$ruleMe    = New-Object System.Security.AccessControl.FileSystemAccessRule($Me,"FullControl","ContainerInherit,ObjectInherit","None","Allow")

$acl = Get-Acl -Path $Path
$acl.SetAccessRuleProtection($false,$true) # 継承有効, 継承 ACE を保持
$acl.ResetAccessRule($ruleAdmin)
$acl.AddAccessRule($ruleSys)
$acl.AddAccessRule($ruleMe)
Set-Acl -Path $Path -AclObject $acl </code></pre>

<h3>フォルダー配下の「不明 SID」を検出→置換</h3>
<pre><code class="language-powershell">$root = "D:\SqlBackups"
$targetSid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-544") # Administrators
Get-ChildItem $root -Recurse -Force | ForEach-Object {
  try{
    $acl = Get-Acl $_.FullName
    $dirty = $false
    foreach($ace in $acl.Access){
      if($ace.IdentityReference.Value -match "^S-1-5-21-"){
        $acl.RemoveAccessRule($ace) | Out-Null
        $dirty = $true
      }
    }
    if($dirty){
      $ar = New-Object System.Security.AccessControl.FileSystemAccessRule($targetSid,"FullControl","ContainerInherit,ObjectInherit","None","Allow")
      $acl.AddAccessRule($ar)
      Set-Acl $_.FullName $acl
      Write-Host "Fixed:" $_.FullName
    }
  }catch{
    Write-Warning $_.Exception.Message
  }
}
</code></pre>

<h2>SQL Server バックアップで起こりがちな落とし穴と対策</h2>
<ul>
  <li><strong>サービス アカウントが誰かを把握</strong>：既定インスタンスなら <code>NT SERVICE\MSSQLSERVER</code>、名前付きなら <code>NT SERVICE\MSSQL$インスタンス名</code>、またはドメイン サービス アカウントのことがあります。出力フォルダーにこのアカウントと運用担当のグループを<strong>事前登録</strong>しましょう。</li>
  <li><strong>バックアップ移送の方法</strong>：ZIP で固めると ACL が失われることがあります。ACL を保持するなら <code>robocopy</code> を推奨。</li>
</ul>
<pre><code>robocopy "D:\SqlBackups" "\\FileSrv\SqlBackups" *.bak /COPY:DAT /DCOPY:DAT /R:1 /W:1 /SEC /SECFIX
</code></pre>
<p><code>/COPY:DAT</code> はデータ・属性・タイムスタンプ、<code>/SEC</code> は DACL 付きコピー、<code>/SECFIX</code> は既存ファイルにもセキュリティを修正適用します。</p>

<h2>安全性の観点（「Everyone=フル」は厳禁）</h2>
<ul>
  <li>一時復旧であっても <strong>Everyone=フル コントロール</strong> は避ける。管理は <strong>Administrators</strong> / <strong>Backup Operators</strong> / 運用グループ で粒度を絞る。</li>
  <li>ドメイン環境では個別ユーザーより <strong>ドメイングループ</strong> に権限を付与し、メンバー管理で運用する。</li>
  <li>「拒否（Deny）」ACE は許可より優先されるため、むやみに追加しない。</li>
</ul>

<h2>トラブル時のチェックリスト</h2>
<table>
  <thead>
    <tr>
      <th>現象</th>
      <th>確認ポイント</th>
      <th>対処のヒント</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>「アクセスが拒否されました」</td>
      <td>管理者でシェルを開いているか、UAC に阻まれていないか</td>
      <td>「管理者として実行」で CMD/PowerShell を起動して再試行</td>
    </tr>
    <tr>
      <td>セキュリティ タブが空</td>
      <td>所有者が Unknown／別 SID になっていないか</td>
      <td><code>takeown</code> と <code>icacls /setowner</code> で回復</td>
    </tr>
    <tr>
      <td>GUI の追加ボタンがグレーアウト</td>
      <td>WRITE_DAC（ACL 書き込み）権限の有無</td>
      <td>所有権を取得後に再度追加</td>
    </tr>
    <tr>
      <td>コピー先でだけ読めない</td>
      <td>コピー手段が ACL を保持しているか</td>
      <td><code>robocopy /SEC</code> や <code>/COPYALL</code> を使用</td>
    </tr>
    <tr>
      <td>フォルダーは直ったが子が直らない</td>
      <td>継承が無効／明示 ACE が残存</td>
      <td><code>icacls /inheritance:e</code> と必要なら <code>/reset</code></td>
    </tr>
  </tbody>
</table>

<h2>ケーススタディ（実務での再現例）</h2>
<h3>ケース1：別サーバーへ .bak を移動後に編集不能</h3>
<p>旧サーバーの SQL サービスが LocalSystem で実行されており、出力 .bak の DACL に LocalSystem と Unknown SID だけが残っていた。新サーバーの管理者で所有権を取得 → Administrators/SYSTEM/運用グループへフル コントロール付与 → 継承有効化で解決。</p>

<h3>ケース2：ドメイン離脱後に Unknown Account だらけ</h3>
<p>PC をワークグループ化したことで、DACL に残っていたドメイン SID がすべて Unknown Account 化。<code>icacls /save</code> で現状保存 → 不明 SID を精査しながら <code>/remove</code> → ローカル Administrators と必要ユーザーのみ再付与で復旧。</p>

<h3>ケース3：大量ファイル（数十万）を一括修復</h3>
<p>GUI は現実的でないため、<code>takeown /r</code> と <code>icacls /T</code> を併用。トラブルに備え、先に <code>icacls /save</code> で直前スナップショットを取得。作業時間短縮のため <code>/grant:r</code> を使い、重複 ACE を置換方式で整理。</p>

<h2>監査と可観測性：だれがいつ ACL を変えた？</h2>
<p>トラブル再発防止には、ACL 変更の監査が役立ちます。</p>
<ol>
  <li>ローカル セキュリティ ポリシー → <strong>ローカル ポリシー</strong> → <strong>監査ポリシー</strong> → <strong>オブジェクト アクセスの監査</strong> を成功/失敗で有効化。</li>
  <li>対象フォルダーの <strong>監査</strong> タブ（SACL）で、変更を監視したいアカウントの「アクセス許可の変更」「所有権の変更」にチェック。</li>
  <li>イベント ビューアーのセキュリティ ログ（代表イベント：4670 権限変更、4663 アクセス、4907 監査設定変更）を定期確認。</li>
</ol>
<pre><code>wevtutil qe Security /q:"*[System[(EventID=4670)]]" /f:text /c:20
</code></pre>

<h2>よくある質問（FAQ）</h2>
<h3>Q. <code>icacls</code> の <code>/grant</code> と <code>/grant:r</code> は何が違う？</h3>
<p><code>/grant</code> は ACE を追加、<code>/grant:r</code> は同一 SID の既存 ACE を置換します。重複 ACE の乱立を防ぎたいときは <code>/grant:r</code> が便利です。</p>

<h3>Q. 所有者を Administrators にするべき？ 自分にするべき？</h3>
<p>運用保守の観点では <strong>Administrators</strong>（グループ）を所有者にしておくと属人化を避けられます。個人ユーザー所有だと離任・退職時に詰まりがちです。</p>

<h3>Q. 「拒否（Deny）」ACE を削除してよい？</h3>
<p>やみくもに消すのは危険です。Deny は許可より強く作用します。誰に、どの権限を、なぜ拒否しているかを理解してから調整してください。迷うときは継承を有効化し、親のポリシーに合わせるのが無難です。</p>

<h3>Q. EFS（暗号化）や BitLocker が原因の可能性は？</h3>
<p>BitLocker はボリューム暗号で ACL とは独立です。EFS はユーザー証明書に紐づくため、別マシンで復号できないとアクセスできません。この場合は EFS の復号または復旧エージェントを使います。症状としては「セキュリティ タブが空」より「暗号化/アクセス拒否」が前面に出ることが多いです。</p>

<h2>運用のベストプラクティス（再発防止）</h2>
<ul>
  <li><strong>バックアップ書き出し先の標準化</strong>：<code>D:\SqlBackups\&lt;Instance&gt;\&lt;YYYYMMDD&gt;</code> のように決め打ちし、フォルダー作成時にテンプレート ACL を適用。</li>
  <li><strong>サービス アカウントと担当グループの事前付与</strong>：<code>Administrators</code>、<code>SYSTEM</code>、SQL サービス アカウント、<code>Backup Operators</code> または「DB_BackupOperators」等のドメイングループに (OI)(CI) で明示付与。</li>
  <li><strong>ACL のドリフト検知</strong>：週次で <code>icacls /save</code> の差分をとり、意図せぬ変更を検出。</li>
  <li><strong>コピーは robocopy で</strong>：ACL を維持したいときは <code>/SEC</code>、差分修正は <code>/SECFIX</code>、ミラーは <code>/MIR</code>。SACL を含め全メタデータも必要なら <code>/COPYALL</code>。</li>
  <li><strong>権限は最小権限の原則</strong>：読み取りだけで足りる担当には R、日次退避のジョブは書き込み＋ファイルの作成（Append）に限定。</li>
</ul>

<h2>GUI と CLI の対応早見表</h2>
<table>
  <thead>
    <tr>
      <th>目的</th>
      <th>GUI 操作</th>
      <th>CLI コマンド</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>所有権の取得（ファイル）</td>
      <td>詳細設定 → 所有者 → 変更</td>
      <td><code>takeown /f "C:\path\file.bak" /a</code></td>
    </tr>
    <tr>
      <td>所有者の設定（管理者）</td>
      <td>—</td>
      <td><code>icacls "C:\path\file.bak" /setowner "Administrators"</code></td>
    </tr>
    <tr>
      <td>権限の付与（フル）</td>
      <td>編集 → 追加 → フル</td>
      <td><code>icacls "C:\path\file.bak" /grant Administrators:F</code></td>
    </tr>
    <tr>
      <td>継承の有効化</td>
      <td>詳細設定 → 継承の有効化</td>
      <td><code>icacls "C:\path\folder" /inheritance:e</code></td>
    </tr>
    <tr>
      <td>未知 SID の削除</td>
      <td>—</td>
      <td><code>icacls "C:\path\file" /remove *S-1-5-21-...</code></td>
    </tr>
    <tr>
      <td>親既定にリセット</td>
      <td>—</td>
      <td><code>icacls "C:\path\folder" /reset /T</code></td>
    </tr>
    <tr>
      <td>ACL のバックアップ</td>
      <td>—</td>
      <td><code>icacls "C:\path" /save ".\acl.txt" /T</code></td>
    </tr>
    <tr>
      <td>ACL の復元</td>
      <td>—</td>
      <td><code>icacls "C:\path" /restore ".\acl.txt"</code></td>
    </tr>
  </tbody>
</table>

<h2>エラーパターンと回避策（深掘り）</h2>
<h3>「アクセスが拒否されました（Access is denied）」が消えない</h3>
<p>所有権取得後も拒否される場合、同時に付与されている「拒否」ACE が効いていることがあります。まず明示 ACE を棚卸しし、Deny を最小化。フォルダー単位なら <code>/reset</code>→<code>/inheritance:e</code>→必要な ACE を <code>/grant:r</code> の順が安定します。</p>

<h3>実行中プロセスがファイルをロックしている</h3>
<p>.bak を別プロセスが掴んでいると ACL 変更が反映されないことがあります。SQL Server、ウイルス対策、バックアップソフトのジョブを一時停止してから再試行します。</p>

<h3>ローカル化されたグループ名の罠</h3>
<p>日本語 OS でもコマンドでは英語名（<code>Administrators</code>）が通るのが一般的ですが、混乱を避けるには前述の SID 指定が堅牢です（例：<code>*S-1-5-32-544</code>）。</p>

<h2>バックアップ運用テンプレート（即使える作業手順）</h2>
<ol>
  <li><strong>バックアップ先を作る</strong>：<code>D:\SqlBackups\Prod</code></li>
  <li><strong>所有者を管理者に</strong>：<code>icacls "D:\SqlBackups\Prod" /setowner "Administrators"</code></li>
  <li><strong>継承有効化</strong>：<code>icacls "D:\SqlBackups\Prod" /inheritance:e</code></li>
  <li><strong>ACE 付与</strong>：
    <pre><code>icacls "D:\SqlBackups\Prod" ^
  /grant:r Administrators:(OI)(CI)F SYSTEM:(OI)(CI)F "Domain\DB_BackupOps":(OI)(CI)M</code></pre>
  </li>
  <li><strong>SQL Agent ジョブの実行アカウント確認</strong>：サービス ログオンまたはプロキシに適切な NTFS 権限があるかチェック。</li>
  <li><strong>週次で ACL スナップショット</strong>：<code>icacls "D:\SqlBackups\Prod" /save "D:\acl-Prod.txt" /T</code></li>
</ol>

<h2>まとめ</h2>
<p>「セキュリティ」タブが空白になったり、ユーザーが表示されず操作不能に見える状態は、所有権と DACL の関係を理解すれば必ず復旧できます。最短は「<strong>所有権を取る → 管理者/SYSTEM/運用グループに付与 →（必要に応じて）継承を戻す</strong>」の三点セット。大量処理や再発防止には <code>takeown</code> と <code>icacls</code>、PowerShell を活用し、バックアップ先フォルダーの事前整備とロールベースの権限設計で安定運用を実現しましょう。</p>

<hr>

<h2>付録：質問への回答（要点抜粋）</h2>
<ul>
  <li><strong>質問：</strong> SQL Server の .bak を保存後、数日で「セキュリティ」タブから SID が消え、名前の変更や削除ができない。「Everyone」を追加しても失敗。どうユーザー（プロファイル）を追加すべき？</li>
  <li><strong>回答：</strong> 管理者でログオンし、所有権を取得してから <strong>Administrators</strong>・<strong>SYSTEM</strong>・必要ユーザー/グループを <strong>編集 → 追加</strong> で付与。GUI が効かない場合は次のコマンドで復旧可能。
    <pre><code>takeown /f "C:\path\backup.bak" /a
icacls "C:\path\backup.bak" /setowner "Administrators"
icacls "C:\path\backup.bak" /grant:r Administrators:F SYSTEM:F "%USERNAME%":F /inheritance:e

さらに Unknown SID が残っていれば icacls /remove &lt;SID&gt; で整理。フォルダー配下は /T と (OI)(CI) を併用し、必要に応じて親からの継承を有効化してください。

付録：セキュリティ配慮メモ

  • Everyone=フルは最後の最後の緊急措置に限定。作業後は必ず撤回。
  • 監査ログ（4670 等）を取得して変更履歴を残す。
  • ドメインでは個人ではなくグループへ権限付与（入退室管理をグループで行う）。

クイックコマンド チートシート

REM 所有権（フォルダー配下すべて）
takeown /f "D:\SqlBackups" /r /d Y /a

REM 所有者を Administrators に
icacls "D:\SqlBackups" /setowner "Administrators" /T

REM 継承を有効化
icacls "D:\SqlBackups" /inheritance:e

REM 主要 ACE をまとめて設定（置換）
icacls "D:\SqlBackups" /grant:r Administrators:(OI)(CI)F SYSTEM:(OI)(CI)F "Domain\DB_BackupOps":(OI)(CI)M /T

REM 不明 SID の削除（例）
icacls "D:\SqlBackups" /remove *S-1-5-21-9999999999-8888888888-7777777777-1234 /T

REM 親の既定にリセット（最終手段）
icacls "D:\SqlBackups" /reset /T

REM ACL バックアップと復元
icacls "D:\SqlBackups" /save "D:\acl.txt" /T
icacls "D:\SqlBackups" /restore "D:\acl.txt"
Windows
PowerShell Windows SQL Server icacls NTFSアクセス許可

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次