アプリ試作でFTP送信をしたいだけなのに、Windows Serverを用意すべきか迷うことがあります。さらに端末やサーバーで、ユーザーに勝手なアプリを入れさせたくない――。本記事では「FTPに本当に必要なもの」と、AppLocker/WDACで“許可したものだけ実行”を実現する考え方を具体的に整理します。
FTPでファイル送信するだけならWindows Serverは不要
まず結論から言うと、「FTPでファイルを送る／受け取る」こと自体のために Windows Serverを新規に用意する必要はありません。必要なのは、あくまでFTPサーバーに接続するためのFTPクライアントであり、これは一般的なWindows 10/Windows 11のPCでも用意できます。
| やりたいこと | Windows Serverが必須か | 現実的な選択肢 |
|---|---|---|
| 既存のFTPサーバーへ、Windows PCからファイル送信したい（クライアント） | 不要 | Windows標準のftp.exe／File Explorer経由、または許可したFTPクライアント |
| 社内で「受け口（FTPサーバー）」を新規に立てたい（サーバー側） | 必須ではない | Linux/NAS/クラウド、またはIISのFTP（Windows Server・一部Windowsクライアント） |
| “FTP”ではなく安全なSFTP/FTPSで運用したい | 不要（要件次第） | OpenSSH（SFTP）やFTPS対応サーバー、クラウドのマネージドSFTP |
混同しやすいポイント：FTPは「送る側」と「受ける側」が別物
「Windows Serverが必要？」という疑問は、たいていFTPサーバーとFTPクライアントの役割が混ざっているときに起きます。
- FTPクライアント：FTPサーバーに接続してファイルをアップロード／ダウンロードする側（あなたのWindows PCなど）
- FTPサーバー：ファイルの受け口として待ち受ける側（社内サーバー、NAS、クラウド、相手先サーバーなど）
あなたが「送信するだけ」なら、手元のWindows PCがFTPクライアントになれば十分です。逆に「受け口を社内に用意する」なら、どこかにFTPサーバー機能が必要になりますが、それはWindows Serverに限定されません。
Windows 10/11でFTP送受信する現実的な方法
方法：標準のftp.exe（コマンド）で送受信する
Windowsには、古くからftp.exeというコマンドラインFTPクライアントが含まれています。対話的に使うことも、スクリプトファイルを渡してバッチ処理することもできます。
対話モードの例
ftp 203.0.113.10
User (203.0.113.10:(none)): youruser
Password:
ftp> binary
ftp> put C:\\work\\prototype.zip
ftp> bye自動化（スクリプト）例
ftp.exeは -s: オプションでコマンドを並べたテキストファイルを実行できます。Windows 8 / Windows Server 2012以降では、スクリプトファイルはUTF-8で作成する必要があります。
ftp -s:C:\\scripts\\upload.txt 203.0.113.10rem upload.txt（UTF-8で保存）
user youruser yourpassword
binary
cd /incoming
put C:\\work\\prototype.zip
bye注意：パスワードを平文でスクリプトに書く運用は避けるのが基本です。プロトタイプ用途でも、可能なら資格情報の扱い（専用アカウント、最小権限、短期間で失効など）をセットで設計してください。
方法：File Explorer（エクスプローラー）からFTPへ接続する
環境によっては、File ExplorerでFTPを「ネットワークの場所」として追加し、GUIでファイル操作したいケースもあります。過去からの方法としては「新しいネットワークの場所の追加」でFTPを登録する手順が知られています。
- 手軽に触れる反面、Windowsのバージョン差分や更新で挙動が変わることがある
- FTPSなど暗号化方式は扱いづらい（対応可否や制限が環境依存になりがち）
- コピー／貼り付けや新規フォルダ作成ができない等、UI上の制約が発生することがある
そのため、運用の再現性を重視するなら「ftp.exeのスクリプト運用」か「SFTP/FTPSの標準化」のほうが、プロトタイプ段階でも後で揉めにくくなります。
FTPを使う前に知っておきたいセキュリティの現実
FTPは便利ですが、一般に安全性の面では古い設計です。資格情報やデータが暗号化されない形で流れるリスクがあり、Microsoftのコミュニティでも「FTPは古く安全性が低い」ため代替を推奨する趣旨の回答が見られます。
| 方式 | 通信の暗号化 | 典型ポート | 使いどころ |
|---|---|---|---|
| FTP | なし（平文になりやすい） | 21（データは別ポート） | 閉域網・検証用途、短期利用（推奨はしにくい） |
| FTPS | TLSで暗号化 | 21/990など（構成次第） | IISなど既存FTP資産の延命、TLSでの保護 |
| SFTP（SSH） | SSHで暗号化 | 22 | インターネット越しや外部連携、運用を単純化したいとき |
| HTTPS（Web/ストレージ） | TLSで暗号化 | 443 | ブラウザでの受け渡し、API連携、クラウドストレージ |
プロトタイプ用途でも、相手が対応できるならSFTP/FTPSへ寄せるだけで、パスワードや成果物の漏えいリスクを大きく下げられます。
代替案：Windows標準のOpenSSHでSFTPを検討する
「Windowsでサーバーを立てる＝Windows Server」という発想になりがちですが、近年のWindowsにはOpenSSHが機能（Feature on Demand）として提供されています。Windows 10 build 1809およびWindows Server 2019以降で、OpenSSHが機能として利用できる旨が案内されています。
OpenSSH Serverを入れると、SSH/SFTP（ポート22）で暗号化されたファイル転送の受け口を用意できます。インストール手順（GUI/PowerShell）や、インストールによりファイアウォール規則が作成される点もMicrosoft Learnに記載されています。
「FTPを使いたい」が本音ではなく「ファイルを安全に受け渡ししたい」が本音なら、プロトタイプの時点でSFTPにしてしまうのは、後工程（検収・監査・本番移行）を楽にする選択になりやすいです。
それでも「WindowsでFTPサーバーを立てたい」ならIISを検討
受け口をWindowsで用意したい場合、代表的なのはIISのFTPサービスです。Microsoft Learnのチュートリアルでも、IISにFTPサービスを追加してFTPサイトを構築するシナリオが紹介されています。
- Windows Serverで運用する（管理・監査・冗長化などの要件を満たしやすい）
- クライアントOSで検証用途として動かす（要件を満たす範囲で）
ただし本番運用では、可用性・ログ・バックアップ・証明書運用（FTPS）・脆弱性対応など、Windows Serverでの運用が現実的になることも多いです。「FTPの送信のため」ではなく「サーバー運用の要件のため」にWindows Serverが必要になる、と理解しておくと判断が整理しやすくなります。
「勝手なアプリを入れさせたくない」問題は、バッチでは解決しにくい
次に、端末OSやサーバーでユーザーに任意のアプリをインストール／実行させたくない、という課題です。ここは発想を切り替えるのがポイントで、バッチスクリプトで“禁止する”のは回避されやすいのが現実です。
理由はシンプルで、Windows上で「実行」には多くの入口があり、バッチで入口を塞いだつもりでも別経路で動いてしまうケースが出やすいからです。さらにユーザーがローカル管理者権限を持っていると、制限は一気に形骸化します。
実務では、次の2つを分けて考えると設計がぶれません。
- インストール禁止：MSI/EXEのインストーラー実行を止める、管理者権限を持たせない
- 実行禁止：コピーしてきた“ポータブルアプリ”も含めて、許可したアプリ以外は起動できないようにする
結局のところ、効果が出るのは「実行禁止」を徹底するホワイトリスト方式です。これをWindows標準の仕組みで実現するのが、AppLockerやWDAC（App Control for Business）です。
AppLocker：許可したアプリだけ実行させる（ホワイトリスト方式）
AppLockerは、ユーザーが実行できるものをルールで制御する仕組みです。実行ファイルだけでなく、スクリプト、Windows Installer、DLL、パッケージアプリなど幅広く対象にできます。
AppLockerで制御できる対象（例）
| 対象 | 拡張子例 | よくある目的 |
|---|---|---|
| 実行ファイル | .exe / .com | 未承認ツールの起動をブロック |
| インストーラー | .msi / .msp / .mst | 勝手なインストールを抑止 |
| スクリプト | .ps1 / .vbs / .js / .bat / .cmd | 持ち込みスクリプトの実行を抑止 |
| DLL（任意） | .dll など | DLL読み込み経路の悪用を抑止（設計は慎重に） |
| パッケージアプリ | .appx など | ストアアプリ含めた利用制御 |
AppLockerが「プロトタイプ環境」に向いている理由
- 監査モード（Audit-only）で影響を可視化してから強制できる（いきなり業務停止を起こしにくい）
- ルールを「署名（Publisher）」ベースで作れるので、アプリ更新に強い（ハッシュ固定より運用しやすい）
- GPOで配布でき、台数が増えても管理が破綻しにくい
押さえるべき要件と注意点
- AppLockerを動かすには Application Identityサービス（appidsvc） が必要です。止まっているとルールが効きません。
- Server CoreではAppLockerがサポートされません（GUIなし運用を前提にしていると詰まりやすい）。
- Windows 10（2004以降）とWindows 11では、特定エディションでなくてもAppLockerポリシーを強制できるようになった旨が案内されています（KB 5024351）。
最小構成の進め方（事故を起こしにくい手順）
いきなり全面禁止にすると、必要なツールまで止まって開発が止まります。プロトタイプ環境では、次の流れが現実的です。
- 標準ユーザー運用に寄せる（ローカル管理者を配らない）
- AppLockerを監査モードで適用し、「何が実行されているか」をログで把握する
- OS標準と開発に必要なツールだけを許可する（署名ベース推奨）
- 例外が出たら“理由のある例外”としてルール化し、運用台帳に残す
- 最後に強制モードへ切り替える
より強固にするならWDAC（App Control for Business）
Microsoft Learnでは、Windowsのアプリ実行制御として「App Control for Business」と「AppLocker」の2つがあると整理されています。さらにアプリだけでなく、スクリプトやMSI、PowerShellの対話セッションまで対象にできること、PowerShellがConstrained Language Modeになることなども説明されています。
また、AppLockerは“防御の深さ（defense-in-depth）”として位置づけられ、より堅牢な保護が目的ならApp Control for Businessを使うべき、という趣旨の注意書きもあります。
WDACはカーネルレベルのコードも含め「何を実行できるか」を縛り、未署名スクリプトやMSIのブロック、PowerShellのConstrained Language Mode適用などができると説明されています。
AppLockerとWDACの使い分け（ざっくり）
| 観点 | AppLocker | WDAC（App Control for Business） |
|---|---|---|
| 導入難易度 | 比較的低い（GPO運用と相性が良い） | 高め（設計・例外管理が重要） |
| 適用単位 | ユーザー／グループ単位も扱いやすい | 基本はデバイス全体（より強固） |
| 守りの強さ | 「まず止めたい」を実現しやすい | カーネル含め強固に縛れる |
| プロトタイプでの現実解 | 監査→強制の段階導入がしやすい | “固定化された端末”や検証専用端末に向く |
Smart App Controlとの関係
Windows 11ではSmart App Controlが提供され、署名済みやクラウド評価で安全と判断されたコードのみを許可する仕組みが説明されています。これは主にコンシューマー向けですが、App Control for Businessと同じ基盤で作られている点も整理されています。
プロトタイプ作業でのおすすめ設計例
「FTPで送る」課題と「勝手なアプリを入れさせない」課題は、別々に見えて実はつながっています。転送の口が増えるほど、持ち込みツールやスクリプトの実行機会も増えるためです。ここでは現実的な落としどころを3パターンで整理します。
| パターン | 転送方法 | アプリ制御 | 向く状況 |
|---|---|---|---|
| 最小構成（短期・少人数） | 既存FTPへftp.exeで送受信 | 標準ユーザー＋必要最小限のツールだけ配布 | 数日〜数週間の検証、端末数が少ない |
| 安全寄せ（外部連携あり） | SFTP（OpenSSH）またはFTPS | AppLocker（監査→強制） | 社外/クラウドを経由、成果物が重要 |
| ロックダウン（端末固定） | SFTP/HTTPSなど統一 | WDAC（App Control for Business） | テスト端末を“設備”として固定運用したい |
よくある詰まりどころと回避策
「インストール禁止」だけでは足りない
インストーラーを止めても、ZIP展開で動くツール（いわゆるポータブルアプリ）は残ります。開発現場ではむしろこちらが多いので、最初から「実行禁止（許可制）」を設計の中心に置くのが安全です。
例外運用が増えるほどルールは壊れる
ホワイトリスト方式は、例外を増やしすぎると結局“何でも動く”に戻りがちです。プロトタイプ段階から、次の基準を決めておくと破綻しにくくなります。
- 例外は「期間」「担当」「理由」「代替案の検討結果」をセットで残す
- 許可ルールは「署名ベース」を優先し、パス許可は最小限にする
- ユーザーが書き込める場所（Downloads/Temp/デスクトップ配下など）を起点にした実行を避ける
FTP運用は“認証情報”がボトルネックになる
プロトタイプでは「とりあえず共有アカウント」で回りがちですが、後から監査やトラブルシュートができません。最低限、次のセットは守るのがおすすめです。
- 個人アカウント（誰が送ったか追える）
- アップロード先フォルダの権限を最小にする（必要な場所だけ）
- 短期プロジェクトならパスワードのローテーションや期限を決める
チェックリスト：判断を早くするための問い
- 「FTPクライアントとして送るだけ」なのか、「受け口のサーバーも新規に用意したい」のか？
- 転送はインターネット越しになるか？ なるならSFTP/FTPS/HTTPSに寄せられるか？
- 端末のユーザーはローカル管理者か？ 標準ユーザーに落とせるか？
- 「禁止したい」のはインストールか、実行か？（多くのケースで実行が本丸）
- AppLockerの監査ログを収集して、許可リストを育てる運用ができるか？
Windows Serverは“FTP送信のため”に必要というより、運用要件（可用性、統制、監査、保守）を満たすために必要になります。まずは送る側はWindowsクライアントで十分という前提で整理し、アプリ制御はAppLocker/WDACで許可制にする――この2点を押さえると、プロトタイプでも本番でもブレない構成を作れます。
コメント