IT & AIテクノロジー

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第7回 セキュリティとベストプラクティス - 本番環境での考慮事項

Qualiteg コンサルティング

Qualiteg コンサルティング

— 8 min read
大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第7回 セキュリティとベストプラクティス - 本番環境での考慮事項

こんにちは、今回はシリーズ第7回セキュリティとベストプラクティス - 本番環境での考慮事項 について解説いたします！

連載の構成

第7章：セキュリティとベストプラクティス

7.1 認証情報の管理

7.1.1 Basic認証のセキュリティリスク

Basic認証は最もシンプルな認証方式ですが、同時に最もリスクが高い方式でもあります。その理由と対策を詳しく見ていきましょう。

【Basic認証の危険性を実演】
セキュリティ研修にて：
講師：「Basic認証がどれだけ危険か、実際に見てみましょう」
1. ネットワークキャプチャ開始（Wireshark）
2. Basic認証でプロキシアクセス
3. キャプチャ結果を確認
パケット内容：
Proxy-Authorization: Basic SlBcdGFuYWthX3Q6UEBzc3cwcmQ=
講師：「この文字列をデコードしてみます」
echo "SlBcdGFuYWthX3Q6UEBzc3cwcmQ=" | base64 -d
結果：JP\tanaka_t:P@ssw0rd
参加者：「パスワードが丸見え！」
講師：「これがBasic認証の現実です」

実際の攻撃シナリオを見てみましょう。

【中間者攻撃（Man-in-the-Middle）】
攻撃者の手口：
1. 公衆Wi-Fiでの盗聴
営業社員：「カフェのWi-Fiでメールチェック」
攻撃者：「同じWi-Fiでパケットキャプチャ」
結果：Basic認証の認証情報を取得
2. ARPスプーフィング
攻撃者：「私がデフォルトゲートウェイです」
クライアント：「じゃあ、あなた経由で通信」
攻撃者：「すべての通信が見える...」
3. 悪意のあるプロキシ
攻撃者：「無料プロキシサービスを提供」
ユーザー：「便利！使おう」
攻撃者：「Basic認証情報を収集」

HTTPSでも完全ではない理由を理解しましょう。

【HTTPS使用時の注意点】
IT管理者：「HTTPSなら暗号化されるから安全？」
セキュリティ専門家：「いくつか注意点があります」
リスク1：最初のプロキシ接続
クライアント → プロキシ：平文（Basic認証）
プロキシ → 外部サイト：HTTPS
つまり、クライアント～プロキシ間が危険
リスク2：SSL/TLSインターセプト
企業プロキシ：「SSL通信を検査します」
方法：中間CA証明書をクライアントにインストール
結果：プロキシがすべてを復号して見られる
リスク3：ログへの記録
プロキシログ：
2024-01-20 10:00:00 Basic SlBcdGFuYWthX3Q6UEBzc3cwcmQ=
→ ログファイルにパスワードが残る

7.1.2 パスワード管理のベストプラクティス

組織として、どのようにパスワードを管理すべきか、具体的な指針を示します。

【パスワードポリシーの策定】
CISO（最高情報セキュリティ責任者）：「新しいパスワードポリシーを導入します」
グループポリシー設定：
コンピューターの構成
└ Windowsの設定
  └ セキュリティの設定
    └ アカウントポリシー
      └ パスワードのポリシー
設定内容：
- パスワードの長さ: 12文字以上（以前は8文字）
- 複雑さの要件: 有効
- パスワードの履歴: 24世代
- 有効期間: 90日
- 最短使用期間: 1日
社員：「12文字は長すぎない？」
CISO：「最新の攻撃手法を考慮すると必要です」

パスワードの複雑さの実例を見てみましょう。

【良いパスワード・悪いパスワード】
セキュリティ研修での説明：
❌ 悪いパスワードの例：
- Password123（よくあるパターン）
- Qualiteg2024（会社名+年）
- Tanaka123!（名前+数字）
- P@ssw0rd（文字置換だけ）
- Spring2024!（季節+年）
✅ 良いパスワードの例：
- MyC@tLikes2EatFish!（文章ベース）
- Tr!9#Qx2$Km8（ランダム）
- Coffee$Sunrise@7AM（複数の単語組み合わせ）
パスフレーズの推奨：
「私は毎朝6時に起きて犬の散歩をする」
→ "Iw@keUp@6AMtoW@lkMyD0g"

サービスアカウントの管理を見てみましょう。

【サービスアカウントの特別な考慮事項】
問題提起：
開発者：「アプリ用のサービスアカウント、パスワード有効期限で止まった！」
解決策1：管理されたサービスアカウント（MSA）
# 作成
New-ADServiceAccount -Name "svc_webapp" -DNSHostName "webapp.jp.qualiteg.com"
# 特徴
- パスワード自動変更（30日ごと）
- アプリケーションは意識不要
- Windows Server 2008 R2以降
解決策2：グループ管理サービスアカウント（gMSA）
# KDSルートキー作成（初回のみ）
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
# gMSA作成
New-ADServiceAccount -Name "svc_webapp_gmsa" -DNSHostName "webapp.jp.qualiteg.com" -PrincipalsAllowedToRetrieveManagedPassword "WebServers"
# 特徴
- 複数サーバーで利用可能
- 完全自動管理

多要素認証（MFA）の導入を見てみましょう。

【パスワード+αの実装】
経営会議：
CEO：「パスワードだけでは不安だ」
CISO：「多要素認証を導入しましょう」
実装例：
1. スマートカード + PIN
   - 物理カード必須
   - PINは短くてもOK（カードがないと無意味）
2. Windows Hello for Business
   - 生体認証（指紋、顔）
   - PIN（デバイス固有）
   - パスワードレス可能
3. FIDO2セキュリティキー
   - USBキー挿入
   - 物理ボタン押下
   - フィッシング耐性
導入結果：
インシデント数：導入前 月5件 → 導入後 月0件

7.1.3 管理者権限の最小化

管理者権限は必要最小限に留めることが、セキュリティの基本原則です。

【過剰な権限の問題】
監査での発見：
監査人：「Domain Adminsグループに50人もいますね」
IT部長：「便利だから、みんなに...」
監査人：「これは重大なリスクです」
リスクの実例：
ヘルプデスク田中：「プリンタードライバーインストールするだけなのに」
権限：Domain Admin（全権限）
ある日：「間違えてAD全体の設定を変更してしまった！」
正しいアプローチ：
必要な権限だけを付与
- プリンタ管理 → Print Operators
- ユーザーパスワードリセット → Account Operators  
- 特定OUのみ管理 → 委任された権限

階層型管理モデル（Tier Model）を見てみましょう。

【管理階層の分離】
Microsoft推奨のモデル：
Tier 0（最重要）：
- ドメインコントローラー
- AD管理者
- 認証システム
→ 専用の管理者、専用の端末
Tier 1（サーバー/アプリ）：
- メンバーサーバー
- アプリケーション
- サーバー管理者
→ Tier 0には触れない
Tier 2（ワークステーション）：
- クライアントPC
- ヘルプデスク
→ サーバーには触れない
実装例：
# Tier別の管理者グループ
- T0-DomainAdmins（5人以下）
- T1-ServerAdmins（サーバー管理）
- T2-WorkstationAdmins（PC管理）

特権アクセス管理ワークステーション（PAW）を見てみましょう。

【PAWの実装】
セキュリティ強化策：
最高権限の作業は専用端末から
PAWの特徴：
- インターネット接続なし
- メール使用不可
- 管理作業専用
- 強化されたセキュリティ設定
構成例：
1. 物理PC or 仮想マシン
2. 最小限のソフトウェア
   - OS + 管理ツールのみ
   - ブラウザなし
3. AppLocker等で実行制御
4. BitLockerで暗号化
運用ルール：
通常業務PC：メール、Web、Office
PAW：AD管理、サーバー設定変更
→ 決して混在させない

7.2 監視とログ

7.2.1 認証ログの取得と分析

適切なログ取得と分析は、セキュリティインシデントの早期発見に不可欠です。

【必要なログの種類】
セキュリティ管理者：「以下のログを収集・保管します」
1. Windowsセキュリティログ
- ログオン成功/失敗（Event ID 4624/4625）
- 特権使用（Event ID 4672）
- アカウントロックアウト（Event ID 4740）
2. プロキシアクセスログ
- ユーザー名
- アクセス先URL
- 日時
- バイト数
3. Active Directoryログ
- ユーザー作成/削除
- グループメンバーシップ変更
- パスワード変更
4. DNSクエリログ
- 不審なドメインへのアクセス
- 大量のNXDOMAIN

ログ収集の自動化を見てみましょう。

【Windows Event Forwarding設定】
# コレクターサーバーでの設定
wecutil qc
# サブスクリプション作成
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
    *[System[(EventID=4624 or EventID=4625 or EventID=4740)]]
    </Select>
  </Query>
</QueryList>
# 各クライアントでの設定
winrm quickconfig

ログ分析の実例を見てみましょう。

【不審なログオンパターンの検出】
PowerShellでの分析スクリプト：
# 深夜のログオンを検出
$suspiciousLogins = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624
    StartTime=(Get-Date).AddDays(-1)
} | Where-Object {
    $_.TimeCreated.Hour -lt 6 -or $_.TimeCreated.Hour -gt 22
} | Select-Object TimeCreated, 
    @{N='User';E={$_.Properties[5].Value}},
    @{N='WorkStation';E={$_.Properties[11].Value}}
# 結果をメール送信
if ($suspiciousLogins) {
    Send-MailMessage -To "security@jp.qualiteg.com" `
        -Subject "深夜ログオン検出" `
        -Body ($suspiciousLogins | Out-String)
}

7.2.2 異常なアクセスパターンの検出

正常な行動パターンを理解し、異常を検出する仕組みが重要です。

【ベースラインの確立】
セキュリティアナリスト：「まず正常なパターンを把握します」
1週間の観察結果：
- 田中さん：平日8:30-18:00、営業システムアクセス
- 山田さん：平日9:00-17:30、経理システムアクセス
- IT部門：24時間（シフト制）、管理システム
異常パターンの例：
- 田中さんが深夜2時にアクセス
- 山田さんが開発サーバーにアクセス
- 短時間で大量のファイルダウンロード

プロキシログでの異常検出を見てみましょう。

【異常なWeb アクセスパターン】
分析スクリプト例：
# 1. 大量データダウンロードの検出
SELECT username, SUM(bytes) as total_bytes, COUNT(*) as requests
FROM proxy_logs
WHERE timestamp > NOW() - INTERVAL 1 HOUR
GROUP BY username
HAVING total_bytes > 1073741824  -- 1GB以上
# 2. 異常な接続先の検出
SELECT username, dst_host, COUNT(*) as count
FROM proxy_logs
WHERE dst_host NOT IN (
    SELECT domain FROM allowed_domains
)
GROUP BY username, dst_host
ORDER BY count DESC
# 3. 認証失敗の急増
SELECT username, COUNT(*) as failed_count
FROM proxy_logs
WHERE status_code = 407
AND timestamp > NOW() - INTERVAL 10 MINUTE
GROUP BY username
HAVING failed_count > 10

地理的異常の検出を見てみましょう。

【不可能な移動の検出】
シナリオ：
09:00 - 東京オフィスからログイン
09:30 - ニューヨークからVPNログイン
分析ロジック：
function checkImpossibleTravel($user, $login1, $login2) {
    $timeDiff = $login2['time'] - $login1['time'];
    $distance = calculateDistance(
        $login1['location'], 
        $login2['location']
    );
        $maxSpeed = 1000; // km/h（飛行機の最高速度）
    $possibleDistance = ($timeDiff / 3600) * $maxSpeed;
        if ($distance > $possibleDistance) {
        alert("不可能な移動検出: $user");
    }
}

7.2.3 定期的な監査の実施

定期的な監査により、設定のドリフトや不正な変更を検出できます。

【月次セキュリティ監査チェックリスト】
監査担当：「毎月第一月曜日に以下を確認」
□ 1. 特権アカウントの棚卸し
   - Domain Adminsメンバー確認
   - 不要なアカウントの削除
   - 最終ログオン日時の確認
□ 2. パスワードポリシーの確認
   - 設定が変更されていないか
   - 例外設定がないか
□ 3. 休眠アカウントの確認
   - 90日以上ログインなし
   - 退職者アカウントの残存
□ 4. サービスアカウントの確認
   - パスワード有効期限
   - 過剰な権限
□ 5. ログ設定の確認
   - 必要なログが取得されているか
   - ログの保存期間

自動監査スクリプトを見てみましょう。

【Active Directory監査スクリプト】
# 月次AD監査レポート生成
# 1. Domain Adminsの確認
$domainAdmins = Get-ADGroupMember -Identity "Domain Admins" | 
    Select-Object Name, SamAccountName, 
    @{N='LastLogon';E={(Get-ADUser $_.SamAccountName -Properties LastLogonDate).LastLogonDate}}
# 2. 90日以上ログインしていないユーザー
$inactiveUsers = Get-ADUser -Filter * -Properties LastLogonDate |
    Where-Object {
        $_.Enabled -eq $true -and 
        $_.LastLogonDate -lt (Get-Date).AddDays(-90)
    } | Select-Object Name, LastLogonDate
# 3. パスワード無期限のユーザー
$passwordNeverExpires = Get-ADUser -Filter {
    PasswordNeverExpires -eq $true -and 
    Enabled -eq $true
} | Select-Object Name, SamAccountName
# 4. 最近作成されたユーザー
$newUsers = Get-ADUser -Filter * -Properties whenCreated |
    Where-Object { $_.whenCreated -gt (Get-Date).AddDays(-30) } |
    Select-Object Name, whenCreated, 
    @{N='CreatedBy';E={(Get-ADReplicationAttributeMetadata $_ -Server DC01 -Properties whenCreated).LastOriginatingChangeUsn}}
# レポート生成
$report = @"
===== Active Directory 月次監査レポート =====
レポート生成日: $(Get-Date -Format "yyyy/MM/dd HH:mm")
1. Domain Admins メンバー (計: $($domainAdmins.Count)名)
$($domainAdmins | Format-Table | Out-String)
2. 90日以上ログインしていないユーザー (計: $($inactiveUsers.Count)名)
$($inactiveUsers | Format-Table | Out-String)
3. パスワード無期限設定のユーザー (計: $($passwordNeverExpires.Count)名)
$($passwordNeverExpires | Format-Table | Out-String)
4. 過去30日間に作成されたユーザー (計: $($newUsers.Count)名)
$($newUsers | Format-Table | Out-String)
"@
# レポート送信
Send-MailMessage -To "security-team@jp.qualiteg.com" `
    -Subject "AD月次監査レポート - $(Get-Date -Format 'yyyy年MM月')" `
    -Body $report -From "ad-audit@jp.qualiteg.com"

コンプライアンス対応を見てみましょう。

【監査ログの保管要件】
法務部門：「各種規制に対応した保管期間を設定してください」
要件例：
- 金融業：7年間
- 医療業：6年間  
- 一般企業：3年間
実装：
1. ログアーカイブサーバー
   - 圧縮して保存
   - 改ざん防止（WORM）
   - 定期的な整合性チェック
2. ログローテーション設定
   /etc/logrotate.d/security-logs
   {
       daily
       rotate 2555  # 7年分
       compress
       delaycompress
       create 0600 root root
       postrotate
           # ハッシュ値を記録
           sha256sum /var/log/security.log.1 >> /var/log/hashes.txt
       endscript
   }
3. 検索可能な状態の維持
   - インデックス作成
   - 必要時に迅速に検索

セキュリティの基本は「予防」「検出」「対応」のサイクルです。これらのベストプラクティスを実装することで、組織の認証基盤をより安全に運用できます。

Read more

Ubuntu 24.04 の GPU サーバーが shutdown で固まる。犯人は HWE カーネルだった

Ubuntu 24.04 の GPU サーバーが shutdown で固まる。犯人は HWE カーネルだった

Ubuntu 24.04 の GPU 推論サーバーが shutdown で固まり、電源長押しになった。前回ブートのジャーナルで追うと、HWE カーネル 7.0 系と NVIDIA 595 open の組み合わせで CUDA プロセスの SIGKILL 直後にページ管理の異常が記録されていた。カーネルと対応する NVIDIA モジュールの組を GA 6.8 系に切り替えて正常な停止を確認し、うっかり HWE に戻らない 4 層の防御まで入れた記録。

By Qualiteg プロダクト開発部
ゼロから作るコーディングエージェント【第5回】ローカルLLMを一級市民にする。16GBのGPU2枚でWebシステムを自走で作らせるまで

ゼロから作るコーディングエージェント【第5回】ローカルLLMを一級市民にする。16GBのGPU2枚でWebシステムを自走で作らせるまで

RTX A5000（24GB）1枚で始めて、ローカルモデル7種類が全滅。RTX A4000（16GB）2枚にQwen3.6-35B-A3BをAWQ 4bitで載せ、fp8のKVキャッシュと98kの文脈で、認証つきWebシステムを3本連続93.8〜96.5点で作らせるまでの構成と落とし穴。モデルの癖、量子化の劣化、文脈長、壊れたツール呼び出しの直し方を、測った数字で書きます。

By Qualiteg プロダクト開発部
ゼロから作るコーディングエージェント【第4回】自走の規律は「人がいない場面」のためのもの。人がいるなら止まって聞く

ゼロから作るコーディングエージェント【第4回】自走の規律は「人がいない場面」のためのもの。人がいるなら止まって聞く

評価ランで鍛えた「止まらない」規律を、人が答えられる場面にまで効かせていました。曖昧な指示に聞き返したモデルを押し戻して勝手に作らせる、断られた確認を形を変えて7回聞き直す、他人のプロセスの止め方を教える。6種類の使い方を演じて出た19件から、人がいる場面の設計と、設定の不備を1行で止める話を書きます。

By Qualiteg プロダクト開発部