2026.08.26 ｜ Writer：竹村

ゼロトラスト導入の進め方｜EDR・MFA導入後に既存のMicrosoft 365・VPNを活かす方法

はじめに

この記事で分かること

EDRとMFAだけではゼロトラスト化と言えない理由
Microsoft 365導入済み企業が次に整備すべき領域
Cisco機器や既存IP-VPNを活かした段階移行の考え方
NTT東日本のManaged SD-WAN、クラウドゲートウェイクロスコネクトの活用方法
中堅企業が失敗しやすいゼロトラスト導入パターン

「ゼロトラストを導入したい」と考える企業は増えています。しかし実際には、EDRを入れた・Microsoft 365に多要素認証を設定した・SSL-VPNで安全にテレワークできる、という段階で「ゼロトラストは導入済み」と考えているケースが少なくありません。

もちろんEDRやMFA（多要素認証）は重要な対策です。しかしそれだけでゼロトラストが完成するわけではありません。

本コラムでは、本社・拠点・データセンター・IP-VPN・Cisco機器を利用中という典型的な境界型ネットワークを持つSMB〜EP規模の企業向けに、Microsoft・Cisco・NTT東日本を組み合わせた現実的なゼロトラスト移行の道筋を解説します。

1. ゼロトラストセキュリティとは: 1-1. EDRやMFAだけではゼロトラストにはならない理由; 1-2. NIST SP 800-207のゼロトラスト7原則
2. ゼロトラストと従来の境界型ネットワークの違い
3. ゼロトラスト構成要素と3社を選ぶ理由: 3-1. Microsoftを中心にする理由; 3-2. Ciscoを組み合わせる理由; 3-3. NTT東日本を組み合わせる理由
4. ゼロトラスト導入ステップと注意事項
5. 移行後の理想構成とサービス選定理由: 5-1. 認証基盤をEntra ID中心へ移行することで、「AD中心」から「ID中心」のアクセス制御へ移行しやすくなること; 5-2. ファイルサーバー移行ではアクセス制御を見直せる; 5-3. サーバー単位ではなくアプリ単位のアクセスに変えられる; 5-4. ログを統合しやすくなる
6. ゼロトラスト移行後の注意点: 6-1. 条件付きアクセスポリシーは定期的に見直す; 6-2. 例外設定を放置しない; 6-3. ログを集めるだけでなく対応手順を決める; 6-4. データセンター内の横展開対策を忘れない; 6-5. バックアップと復旧訓練もゼロトラストに含める
7. Microsoftメインのゼロトラスト導入事例: 7-1. NTTドコモビジネス（旧：NTTコミュニケーションズ）; 7-2. 乃村工藝社; 7-3. スカパーJSAT
8. よくある質問: 8-1. 多要素認証とEDRを導入済みの場合、次に何をすべきですか？; 8-2. 既存のActive DirectoryやデータセンターはすぐにAzureへ移行すべきですか？; 8-3. ゼロトラスト導入で現場の利便性が下がるのを防ぐには？
9. まとめ

1. ゼロトラストセキュリティとは

従来型セキュリティは「社内ネットワークは信頼できる」という境界防御を前提とします。一方、ゼロトラストセキュリティは社内外を問わず、ユーザー、デバイス、アプリケーションの状態を都度検証し、必要最小限のアクセスのみを許可する考え方です。

1-1. EDRやMFAだけではゼロトラストにはならない理由

情シス担当者からよく聞く誤解がこちらです。

多要素認証を入れたのでゼロトラスト化できた
EDRを入れたので侵入されても問題ない
SSL-VPNに多要素認証を設定したので安全

これらはゼロトラストの一部ではありますが、十分ではありません。多要素認証は本人確認を強化しますが、認証後にユーザーがどのサーバーへアクセスできるか、端末が安全な状態か、異常操作をどう止めるかまでは制御できません。EDRも重要ですが、侵入後の横展開を防ぐネットワーク分離・管理者権限の制御・ログの相関分析と組み合わせなければ、被害範囲を限定できないケースがあります。

1-2. NIST SP 800-207のゼロトラスト7原則

ゼロトラストを理解するうえで参照すべきがNIST SP 800-207「Zero Trust Architecture」です。NISTはゼロトラストを「ネットワーク上の場所だけを根拠に暗黙的な信頼を与えない」考え方と説明しています。

出典：NIST「SP 800-207, Zero Trust Architecture」

横にスクロールします

NIST原則	実装例
1. すべてのデータソースとコンピューティングサービスをリソースとみなす	サーバー・SaaS・ファイル・基幹システムをすべて保護対象にする
2. ネットワークの場所に関係なく、すべての通信を保護する	社内LAN・拠点・テレワークのどこからでも同じ前提で確認する
3. 企業リソースへのアクセスはセッションごとに許可する	一度ログイン（認証結果）を恒久的に信頼するのではなく、リソースやセッション、リスクの変化に応じてアクセスを評価する
4. アクセスは動的なポリシーで判断する	ユーザー・端末状態・場所・リスクを組み合わせて判断する
5. すべての資産の整合性とセキュリティ状態を監視・測定する	IntuneやDefender、Cisco ISEで端末・ネットワーク機器の状態を把握する
6. 認証と認可は動的に実施し、アクセス前に厳格に適用する	Entra IDの条件付きアクセスでアプリ単位に制御する
7. 資産・ネットワーク・通信の状態を収集し、改善に活用する	Defender XDR・Sentinelでログを分析し、ポリシー改善につなげる

ゼロトラストは特定の製品名ではなく、アクセス制御・端末管理・ネットワーク制御・データ保護・監視運用を組み合わせた設計思想です。

2. ゼロトラストと従来の境界型ネットワークの違い

ではもう少し踏み込んでみましょう。

今回想定する既設環境は典型的な境界型ネットワークです。本社・複数拠点・データセンターをIP-VPN（弊社：VPNワイド等）で接続し、テレワークはSSL-VPNで社内ネットワークに接続、ネットワーク機器はCisco中心、会社PCには多要素認証とEDRを導入済みという構成です。サーバー類はオンプレにMicrosoft Windows Server、クラウドアプリはMicrosoft 365を中心とした典型的な構成です。

横にスクロールします

観点	従来の境界型ネットワーク	ゼロトラスト型ネットワーク
信頼の前提	社内ネットワーク内は比較的信頼する	社内外を問わず、毎回確認する
守る対象	ネットワーク境界	ユーザー・端末・アプリ・データ・通信
テレワーク	SSL-VPNで社内に引き込む	アプリ単位で必要なリソースにのみ接続する
認証	ログイン時の本人確認が中心	ユーザー・端末状態・場所・リスクを継続的に確認
横展開対策	VLANやFWで大きく分離	アプリ・端末・ID単位で細かく制御
ログ活用	機器ごとにログを確認	ID・端末・SaaS・データのログを相関分析
事故対応	侵入後にネットワーク遮断・端末隔離	検知後にアカウント停止・端末隔離・アクセス遮断を自動化

従来の境界型ネットワークは、ファイアウォールやSSL-VPNが突破されると、侵入した攻撃者が社内システムへ横展開（ラテラルムーブメント）しやすいという課題があります。

一方、ゼロトラスト型のアクセス制御基盤では、社内・社外を区別せず、ユーザー、端末、場所、リスク、アプリケーションなどの情報を継続的に確認することで、不正アクセスの拡大を防ぎやすくし、侵害時の被害範囲の最小化につなげることができます。

3. ゼロトラスト構成要素と3社を選ぶ理由

ゼロトラスト導入では単一製品では完結しません。ゼロトラストを構成する要素を分解すると、おおむね次の5つの領域に整理できます。

横にスクロールします

構成要素	役割	今回の担当
ID・アクセス管理(IAM)	誰が、どの権限で、どの条件下でアクセスできるかを制御する	Microsoft(Entra ID)
端末管理・コンプライアンス	端末が安全な状態かを継続的に確認し、アクセス可否に反映する	Microsoft(Intune)
脅威検知・対応(XDR/SIEM)	端末・ID・SaaS・ネットワークのログを横断的に分析し、異常を検知・対応する	Microsoft(Defender XDR、Sentinel)
データ保護(DLP)	データの所在や持ち出し経路を可視化し、漏えいを防ぐ	Microsoft(Purview)
ネットワーク制御・分離	拠点間通信、オンプレLAN、データセンター内のセグメンテーションを行う	NTT東日本(Managed SD-WAN等)、Cisco(ISE、Secure Firewall)

この5領域がそれぞれ独立して動くのではなく、IDと端末の状態がネットワークアクセスの判断に使われ、ネットワーク機器のログが脅威検知に統合される、というように相互に連携することがゼロトラストの本質です。今回の構成ではMicrosoftを中心に、ネットワークはNTT東日本、オンプレはCiscoと役割を分担し、ゼロトラストを支えるネットワーク・セキュリティ基盤を構成します。なお、SASEとして整理する場合は、SWG、CASB、ZTNA、FWaaS、SD-WANなどの要件を満たす範囲を個別に確認する必要があります。

3-1. Microsoftを中心にする理由

SMB〜EP規模の企業では既にMicrosoft 365を利用しているケースが多く、ゼロトラストの中核となるID・端末・メール・SaaS・データ保護・ログ分析をMicrosoft製品群で関連付けて運用できます。

Entra IDの条件付きアクセスはNISTの第3・4原則に対応し、Intune・Defender XDR・Purview・Sentinelと組み合わせることで、複数の管理画面を横断しつつも、ID・端末・脅威・データ・ログを関連付けて運用しやすくなります。Microsoftのゼロトラストでは「明示的に検証する」「最小特権アクセスを使用する」「侵害を前提とする」の三原則が示されています。

出典：Microsoft Learn「Zero Trust with unified security operations」

3-2. Ciscoを組み合わせる理由

Microsoftが多くの企業でID・端末管理基盤として広く使われているのと同様に、Ciscoはスイッチ・ルーター・ファイアウォールといったネットワーク機器として世界最大のシェアを有し、多くの企業の本社・拠点・データセンターに既に導入されています。ゼロトラストへの移行にあたって、こうした既設のCisco機器をすべて置き換える必要はなく、オンプレLAN・データセンター内ネットワークの可視化や制御では既存資産を活かす方が現実的です。

特にCisco ISEは「誰が、どの端末で、どのネットワークへ接続しているか」を判断するためにゼロトラスト上有効で、Cisco Secure Firewallは既存オンプレミス環境におけるL4〜L7レベルのネットワークセグメンテーションやセグメント間通信制御を担います。Azure上のネットワーク制御については、Azure Firewall、NSG、Application Security Group、Entra Private Accessなども選択肢となるため、配置場所や運用要件に応じて役割分担を整理します。

既存Cisco機器のログはMicrosoft Sentinelへ連携することで統合監視にも活用できます。つまり、すでにCisco機器が稼働している環境であれば、IDと端末管理はMicrosoft、オンプレネットワークの信頼判定と分離はCiscoという形で、既存投資を活かしながらゼロトラストの構成要素を埋めていくことができます。

出典：Cisco「Cisco Identity Services Engine」

3-3. NTT東日本を組み合わせる理由

既存IP-VPNを活かしながら段階的にSD-WAN化し、Azureとの接続を閉域で整備する点でNTT東日本が有効です。Managed SD-WANはSD-WAN技術を活用して拠点間ネットワークを一元管理し、通信先などに応じた経路制御やインターネットブレイクアウトが可能です。クラウドゲートウェイクロスコネクトはNTT東日本の閉域ネットワークからAzureへ接続できるサービスで、Azure ExpressRouteと組み合わせることでデータセンター・拠点・Azureをパブリックインターネットを経由せず安定接続できます。

出典：NTT東日本「Managed SD-WAN」

出典：NTT東日本「クラウドゲートウェイクロスコネクト」

本製品のお問い合わせはこちら

4. ゼロトラスト導入ステップと注意事項

ゼロトラスト移行は一括更改ではなく段階移行が現実的です。

Step 1：守るべき対象を棚卸しする: ユーザー・端末・アプリ・データ・ネットワーク・権限を洗い出し、「止まると業務影響が大きいシステム」「漏えいすると損害が大きいデータ」「攻撃者に狙われやすい管理者権限」から優先順位を付けます。製品選定より先に行うことが鉄則です。
Step 2：Entra IDを中心にIDを統合する: 既存ADとEntra IDを連携し、MFA・条件付きアクセス・管理者アカウント分離・レガシー認証の制限を実施します。多要素認証を全ユーザーに一律設定して終わりにしないことが重要で、端末準拠状態・場所・サインインリスクを組み合わせた動的ポリシーの設計が必要です。
Step 3：Intuneで端末準拠状態を管理する: OSバージョン・ディスク暗号化・Defender稼働・会社管理端末かどうかを条件に設定し、「IDとパスワードとMFAが正しくても、未管理端末や非準拠端末から重要リソースへアクセスできる」状態を低減します。
Step 4：Defender XDRで脅威検知を統合する: EDRを入れるだけでなく、誰がアラートを見るか・重大度ごとの対応フロー・端末隔離の判断基準・誤検知時の業務復旧まで運用設計することが不可欠です。
Step 5：SaaSとデータを可視化する: Defender for Cloud AppsでSaaS利用・シャドーIT・クラウドアプリのリスクを可視化し、Microsoft Purviewで情報分類、DLP、監査、保持などのデータガバナンスを段階的に整備します。「データがどこにあるか」だけでなく「誰がどの端末からどう持ち出そうとしているか」を見る設計が必要です。
Step 6：Managed SD-WANへ段階移行＋Azure閉域接続を整備する: NTT東日本Managed SD-WANで拠点間通信を集中管理し、Microsoft 365トラフィックのローカルブレイクアウトを設定します。並行してクラウドゲートウェイクロスコネクト＋ExpressRouteでAzureとの閉域接続を確立し、データセンターからのハイブリッド移行を段階的に進めます。
Step 7：Cisco ISEでオンプレLANの信頼を見直す: 社内LANに接続した端末を無条件に信頼しない構成にします。会社管理端末のみ業務ネットワークへ、ゲスト端末はインターネットのみ、未管理端末は隔離ネットワークへ振り分けることで、侵入後の横展開を制限します。

横にスクロールします

失敗	内容	回避策
製品導入が目的になる	EDR・MFAを入れて満足する	どのリスクを下げるかを先に定義する
一気に全社展開する	条件付きアクセス・DLPで業務影響が出る	部門・アプリ単位で段階導入する
例外アカウントが残る	共有ID・退職者ID・旧管理者IDが放置される	特権IDと例外IDを定期棚卸しする
ログを見る人がいない	SentinelやDefenderにアラートがたまる	一次対応・エスカレーションフローを決める
ネットワーク分離が粗い	一度侵入されるとDC内を横展開される	重要システム単位でセグメントを見直す

5. 移行後の理想構成とサービス選定理由

横にスクロールします

領域	サービス	役割	選定理由
ID管理	Microsoft Entra ID	認証・SSO・条件付きアクセス	ゼロトラストの起点。M365利用企業で統合しやすい
端末管理	Microsoft Intune	MDM・コンプライアンス管理	条件付きアクセスと連携し管理端末のみ許可できる
EDR/XDR	Microsoft Defender XDR	端末・ID・SaaSの脅威検知	Microsoftログを横断分析できる
SaaS管理	Defender for Cloud Apps	シャドーIT可視化・CASB	見えないSaaS利用をノーコードで把握できる
データ保護	Microsoft Purview	DLP・情報保護	クラウド移行時の情報漏えい対策に有効
統合監視	Microsoft Sentinel	SIEM・ログ相関分析	Cisco機器ログも含め統合監視できる
ZTNA	Microsoft Entra Private Access	ユーザー・端末・条件付きアクセスポリシーに基づき、許可されたプライベートアプリへアプリ単位で接続する	従来のVPNよりも細かく、アプリケーション単位でアクセス制御できる
拠点間接続	NTT東日本 Managed SD-WAN	拠点間閉域接続・集中管理	通信を宛先によって最適化やローカルブレイクアウトが可能かつ、SD-WANとしては比較的容易に導入可能
Azure閉域接続	クラウドゲートウェイクロスコネクト	閉域ネットワークからAzureへ接続	ExpressRouteと組み合わせ安定的な接続が可能
DC↔Azure接続	Azure ExpressRoute	オンプレとAzureのプライベート接続	インターネット非経由のハイブリッド接続
LAN制御	Cisco ISE	端末・ユーザー認証・LAN制御	既存Cisco機器を活かしオンプレLANの信頼を見直せる
ネットワーク境界・分離	Cisco Secure Firewall	セグメント間通信制御	L4〜L7レベルのオンプレセグメンテーションに適する
DNS/Web保護	Microsoft Entra Internet Access / Cisco Umbrella	SWG・Webアクセス制御	既存運用に合わせて選定し、必要に応じてCASB、ZTNA、FWaaS、SD-WANとの役割分担を整理する

上記を踏まえて構成したものが以下の構成図になります。

移行後の構成の目を引く点としてオンプレにあったサーバーをMicrosoft Azureにクラウドリフトしているところです。これには理由があります。

5-1. 認証基盤をEntra ID中心へ移行することで、「AD中心」から「ID中心」のアクセス制御へ移行しやすくなること

オンプレのWindows Server環境では、Active Directoryを中心にして、社内LANに入った端末やユーザーをある程度信頼する設計になりがちです。

Azureへの移行とあわせて、Entra ID連携、条件付きアクセス、SaaS化、アプリ単位の公開を設計することで、次のような構成にしやすくなります。

Active DirectoryとMicrosoft Entra IDの連携
Entra IDによるクラウド認証
条件付きアクセス
Defender XDRによるID・端末・クラウドの統合監視

つまり、従来の「社内ネットワークにいるから信頼する」から、誰が、どの端末で、どこから、どのアプリへアクセスするのかを毎回確認する設計へ移行しやすくなります。

5-2. ファイルサーバー移行ではアクセス制御を見直せる

Windows Server中心の環境では、ファイルサーバーの共有フォルダ権限が長年積み重なり、次のような状態になっていることが多いです。

退職者や異動者の権限が残っている
部門横断で過剰なアクセス権がある
共有IDや管理者権限が残っている
誰が重要ファイルにアクセスしたか追いにくい

Azure Filesは、Azure上で提供されるフルマネージドのクラウドファイル共有サービスです。共有スナップショット、Azure Backup、ソフト削除、Private Endpointによるアクセス経路の制限、アクセス制御、Defender for Storageによる脅威検知などを組み合わせることで、ランサムウェアや不正アクセスへの対策を強化できます。

5-3. サーバー単位ではなくアプリ単位のアクセスに変えられる

オンプレ環境では、SSL-VPNで社内ネットワークに入ると、必要以上に広い範囲へ到達できる構成になっていることがあります。

Azureへの移行とあわせて、Entra ID認証、条件付きアクセス、アプリ単位の公開、ネットワーク制御を設計すると、以下のように構成しやすくなります。

Azure上の業務アプリに対してEntra ID認証を適用
条件付きアクセスで端末状態や場所を確認
Entra Private AccessやApplication Proxyでアプリ単位に公開
NSGでサブネットやネットワークインターフェイス単位の通信を制御し、Azure FirewallでVNet間・インターネット向け通信の集中制御やFQDN、脅威インテリジェンスを活用
管理アクセスはPrivileged Identity Managementで制御

これにより、従来の「VPNで社内LANに入る」形から、必要なアプリに対して、場所に依存せず、ID・端末状態・リスクに基づいてアクセスを制御する設計へ近づけられます。

5-4. ログを統合しやすくなる

ゼロトラストでは、アクセスを制御するだけでなく、ログを集約・相関分析し、異常を早期に検知して、調査・封じ込め・復旧につなげる運用が重要です。

Azureへ移行すると、以下のログをMicrosoft SentinelやDefender XDRに集約しやすくなります。

Entra IDのサインインログ
条件付きアクセスの結果
Defender for Endpointの端末アラート
Azure VMやAzure Firewallのログ
Microsoft 365の監査ログ
オンプレADやCisco機器のログ

これにより、たとえば「不審なサインイン後にファイルアクセスが急増した」「管理者権限で通常と異なる操作が行われた」といった相関分析がしやすくなります。

クラウドリフトについての相談事項は是非NTT東日本にご相談ください。

お問い合わせはこちら

6. ゼロトラスト移行後の注意点

6-1. 条件付きアクセスポリシーは定期的に見直す

組織変更・業務アプリ追加・テレワークルール変更に合わせて、四半期ごとのポリシーレビューを運用として組み込みます。

6-2. 例外設定を放置しない

MFA除外ユーザー・共有アカウント・退職者の残存ID・古い管理者アカウントなどの例外設定は、攻撃者に悪用されるリスクがあるため注意が必要です。例外には必ず期限を設け、定期棚卸しを実施します。

6-3. ログを集めるだけでなく対応手順を決める

Sentinelを導入してもアラートを確認する担当者と対応フローがなければ効果は限定的です。重大度ごとの一次対応・端末隔離の判断基準・経営層への報告基準を事前に決めておきます。

6-4. データセンター内の横展開対策を忘れない

Azureへの移行を進めても基幹システムがDCに残る企業は多くあります。ADサーバー・バックアップサーバー・管理サーバーへの通信要件を整理し、必要最小限の通信に絞るべきです。

6-5. バックアップと復旧訓練もゼロトラストに含める

バックアップが改ざんされないか・復旧に何時間かかるか・代替業務手順があるかを確認し、復旧訓練を実施することが、ランサムウェア対策の実効性を高める重要な要素です。

7. Microsoftメインのゼロトラスト導入事例

7-1. NTTドコモビジネス（旧：NTTコミュニケーションズ）

ゼロトラストに基づくハイブリッドワーク環境を実現するため、従業員IDをEntra IDへ、約40,000台のデバイス管理をIntuneへ移行。ID認証とデバイス管理をクラウド中心に統合した事例です。

出典：Microsoft Customer Stories

7-2. 乃村工藝社

SSE製品の導入後、クラウドサービスのリスク評価に課題があったことからDefender for Cloud Appsとの連携を開始。その後Defender for Endpoint・Intuneを含むMicrosoft 365 E5のセキュリティ機能を活用し、ゼロトラストセキュリティを実現した事例です。

出典：Microsoft Customer Stories

7-3. スカパーJSAT

事業継続を見据えたセキュリティ強化のため、Defender for Endpoint・Intune・Entra ID Protectionを活用し、IT資産を把握・管理できる体制を整備。Microsoft 365 E5への短期移行を実現した事例です。

出典：Microsoft Customer Stories

8. よくある質問

8-1. 多要素認証とEDRを導入済みの場合、次に何をすべきですか？

Entra IDの条件付きアクセスとIntuneの端末準拠状態を連携させることが次のステップです。ゼロトラストでは「誰が」「どの端末で」「どこから」「どのアプリやデータへ」アクセスするかを総合的に判断します。管理された準拠端末からのみ重要なアプリやデータへアクセスを許可する仕組みを優先的に整備しましょう。

8-2. 既存のActive DirectoryやデータセンターはすぐにAzureへ移行すべきですか？

すぐに移行する必要はありません。まずはEntra IDと既存ADを連携し、クラウドIDを中心とした認証基盤を整備します。その後、移行しやすいシステムからSaaS化やAzure移行を進めるのが一般的です。レガシーシステムについては、当面はオンプレミス環境を維持しながら段階的に移行する方法が現実的です。

8-3. ゼロトラスト導入で現場の利便性が下がるのを防ぐには？

最初から厳しすぎるポリシーを全社適用しないことが重要です。通常の会社PCからのアクセスはSSOでスムーズにし、未知の場所・未管理端末・リスクの高いサインイン時のみ追加認証を求める設計が有効です。DLPもまず検知・通知から始め、業務影響を確認しながら段階的に制御を強めると導入しやすくなります。

9. まとめ

ゼロトラスト導入は、EDRや多要素認証を導入して終わりではありません。社内ネットワークを無条件に信頼せず、ユーザー・端末・アプリ・データ・ネットワーク・ログを組み合わせて、アクセスのたびに確認し、異常を早期に検知して、アカウント停止、端末隔離、アクセス制限、調査・復旧へつなげられる運用を整えることが重要です。

本社・拠点・データセンターをIP-VPNで接続し、Cisco機器を中心にオンプレネットワークを運用している企業では、次のような段階移行が現実的です。

Microsoft Entra IDでIDと条件付きアクセスを統合する
Microsoft Intuneで端末準拠状態を管理する
Microsoft Defender XDRで脅威検知を統合する
Defender for Cloud AppsとPurviewでSaaSとデータを保護する
NTT東日本Managed SD-WANで拠点間ネットワークを最適化する
クラウドゲートウェイクロスコネクト＋Azure ExpressRouteで閉域接続を整備する
Cisco ISE・Cisco Secure FirewallでオンプレLANとDC内の信頼を見直す
Microsoft Sentinelでログを統合し、運用改善につなげる

NTT東日本では、クラウド導入・Azure接続・拠点間ネットワーク・情報セキュリティ対策・運用支援まで、企業の既存環境に合わせてワンストップでご支援します。

「ゼロトラストを導入したいが、何から始めればよいか分からない」「Microsoft 365は使っているが、セキュリティ機能を十分に活用できていない」「IP-VPNやデータセンターを活かしながら、AzureやSaaS活用を進めたい」「Cisco機器を活かしたまま、ゼロトラスト構成へ移行したい」

このような課題をお持ちの場合は、ぜひNTT東日本へご相談ください。現状ネットワークの棚卸しから、Microsoft・Cisco・NTT東日本を組み合わせたゼロトラスト導入計画まで、段階的な移行を支援します。

こんな悩みをお持ちの方はぜひお問い合わせください！

Microsoft 365を利用している
VPN更改が近い
Cisco機器を利用している
拠点数が5拠点以上
Azure活用を検討している

お問い合わせはこちら

Microsoft Azure及び、記載のあるMicrosoftサービスはMicrosoft Corporationの米国及びその他の国における登録商標または商標です。
Cisco ISEおよび記載のあるCiscoの各サービス名は、Cisco Systems, Inc.およびその関連会社の米国その他の国における商標または登録商標です。