はじめに
Windowsのリモート管理における「WinRM」と「SSH」。以前は「WindowsならWinRM、LinuxならSSH」と住み分けられていましたが、現在はWindows ServerもOpenSSHを正式サポートしており、どちらを選ぶべきか迷う場面が増えています。
この記事では、セキュリティの観点から両者を徹底比較し、環境に応じた選択基準を整理します。
対象環境
- Windows Server 2019 / 2022、Windows 10 / 11
- 各コマンドは管理者権限のPowerShellで実行してください。
1. WinRM（Windows Remote Management）のセキュリティ
WinRMは、HTTP/HTTPSをベースとしたWS-Managementプロトコルを使用します。PowerShell Remotingの通信基盤でもあり、Enter-PSSession や Invoke-Command はWinRMの上で動作しています。
強み：Active Directoryとの親和性
WinRMの最大のメリットはKerberos認証との親和性です。ドメイン環境では追加設定なしに強力な認証が利用でき、GPO（グループポリシー）による一括構成・PowerShell Remotingとのシームレスな統合が可能です。
懸念点①：HTTPポートの誤解
WinRMには「HTTP（5985）」と「HTTPS（5986）」の2つの待受ポートがあります。
- HTTP（5985）： 通信の「暗号化」について注意が必要です。Kerberos認証を使う場合、メッセージ本体はSPNEGOラッパーによって暗号化されますが、これはHTTPSとは本質的に異なります。HTTPSはTLSによるトランスポート層全体の保護であるのに対し、Kerberosのメッセージ暗号化はあくまでペイロードレベルの保護です。ワークグループ環境でKerberosが使えない場合、通信内容が実質的に平文に近い状態になるリスクがあります。
- HTTPS（5986）： 証明書の発行・更新・配布が必要になり、運用コストが高まります。ただし、AD CS（Active Directory証明書サービス）がある環境では自動配布も可能です。
懸念点②：NTLMの利用に注意
認証方式としてNTLMも選択できますが、NTLMはリレー攻撃（Pass-the-Hash / NTLM Relay）に対して脆弱であり、積極的な利用は推奨できません。ドメイン環境ではKerberos認証を強制し、NTLMをフォールバックさせない設定を徹底してください。
# ネットワークセキュリティ：LANマネージャーの認証レベルを確認
# レベル5（NTLMv2のみ許可・Kerberosを優先）が推奨
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
2. SSH（Secure Shell）のセキュリティ
かつてはサードパーティ製ソフトが必要でしたが、現在はOpenSSH for WindowsとしてOS標準搭載されています（Windows Server 2019以降・Windows 10 1809以降）。
# インストール確認
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'
# インストールと自動起動設定
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
強み：デフォルトでセキュア
SSHは設計段階から「すべての通信を暗号化する」ことが前提となっており、証明書インフラなしでも強力なトランスポート層暗号化が提供されます。
- 公開鍵認証： パスワード認証を禁止し公開鍵認証のみに制限することで、ブルートフォース攻撃をほぼ完全に無効化できます。
- シンプルさ： AD CSのような複雑なPKIインフラがなくても、堅牢な暗号化通信が可能です。
懸念点①：デフォルトポートはスキャンの標的になりやすい
SSHのデフォルトポート22は、インターネット上で常時スキャンされています。インターネット公開サーバーでは、ポートを変更するか、ファイアウォールで接続元IPを制限することを強く推奨します。
# C:\ProgramData\ssh\sshd_config を編集してポートを変更
# Port 22 → Port 2222（例）
# 変更後はssdサービスを再起動
Restart-Service sshd
懸念点②：Windows固有の権限管理
SSH経由でWindowsにログインした場合、JEA（Just Enough Administration） のようなWindows固有の詳細な権限制限をWinRMと同様に適用するのは難易度が高い側面があります。対処としては以下の方向性があります。
- SSH subsystemとしてPowerShellを指定し、その中でJEAエンドポイントに接続する
- Windowsの権限管理が必須の場面ではWinRMを温存し、SSHはファイル転送（SFTP）や汎用コマンド実行に限定する
3. 直接比較表
| 比較項目 | WinRM | SSH |
|---|---|---|
| トランスポート暗号化 | HTTPS時のみ完全暗号化（HTTP+Kerberosは部分的） | 常に完全暗号化 |
| 認証方式 | Kerberos（推奨）、NTLM（非推奨）、証明書 | 公開鍵認証（推奨）、パスワード |
| デフォルトポート | 5985 / 5986 | 22（スキャン対象になりやすい。変更推奨） |
| 設定の容易さ | ドメイン+GPOなら非常に楽 | sshd_configの編集が必要。鍵配布はやや手間 |
| クロスプラットフォーム | Windowsのみ | Windows / Linux / macOS |
| AD/GPO連携 | ネイティブ対応 | 要カスタマイズ |
| JEA連携 | ネイティブ対応 | 設定がやや複雑 |
| PowerShell Remoting | ネイティブ | 設定でSSH経由も可能 |
4. 結局、どちらがセキュアなのか？
「管理環境と要件」によって最適解が異なります。
WinRMを優先すべきケース
- Active Directoryドメイン環境： GPOによる一括管理とKerberosによるSSO（シングルサインオン）が利用でき、Windows管理のエコシステムの中では非常に強固かつ効率的です。
-
PowerShell Remotingを多用する場合：
Invoke-Commandによるリモートスクリプト実行や、JEAを使った権限委任はWinRMが前提です。
SSHを優先すべきケース
- ハイブリッド環境（Windows/Linux混在）： 「公開鍵認証」という一貫したセキュリティポリシーをOSを問わず適用できます。
- ワークグループやクラウド環境： Kerberosが使えない環境ではWinRMのHTTPは危険です。SSHなら証明書管理のオーバーヘッドなしに安全な通信を確保できます。
- インターネット越しの管理： WinRMのポートをインターネットに公開するのはリスクが高く、SSHの方が実績・ツールともに成熟しています。
5. 要塞化のためのベストプラクティス
WinRMの要塞化
# 1. HTTPリスナーを削除（HTTPSのみに制限）
Remove-WSManInstance -ResourceURI winrm/config/listener `
-SelectorSet @{Address="*"; Transport="http"}
# 2. 現在のリスナーを確認（HTTPSのみ残っていればOK）
Get-WSManInstance -ResourceURI winrm/config/listener -Enumerate
# 3. 接続元IPをファイアウォールで制限（管理端末のIPのみ許可）
New-NetFirewallRule -DisplayName "WinRM-HTTPS-Restrict" `
-Direction Inbound -Protocol TCP -LocalPort 5986 `
-RemoteAddress "192.168.10.0/24" -Action Allow
SSHの要塞化
C:\ProgramData\ssh\sshd_config を編集します。
# パスワード認証を無効化（公開鍵認証のみ許可）
PasswordAuthentication no
# rootに相当するAdministratorの直接ログインを禁止
PermitRootLogin no
# 空パスワードを禁止
PermitEmptyPasswords no
# 使用する認証方式を明示
AuthenticationMethods publickey
# 設定ファイル編集後にサービスを再起動
Restart-Service sshd
# 設定が有効になったか確認
ssh -v user@hostname 2>&1 | Select-String "Authentication"
共通のベストプラクティス
-
管理者権限での直接ログインを禁止： 通常ユーザーでログインし、必要な時だけ
sudo相当（Run as Administrator/ JEA）で昇格させる運用を徹底する。 - 接続元IPを必ずホワイトリスト化： どちらのプロトコルも、管理用ポートはインターネット全開放しない。
- ログの集約監視： 不正アクセスの試みをSIEMやAzure Monitorで検知できるようにしておく。
まとめ
現代のWindows管理においては、「ドメイン内はWinRM（Kerberos + HTTPS）、クロスプラットフォームやクラウドはSSH（公開鍵認証）」という使い分けが最もバランスの取れた選択です。
どちらか一方に統一する必要はありません。重要なのは、選んだプロトコルの弱点を理解した上で、適切な要塞化設定を怠らないことです。