Agenda sec の基本 IKE(Internet Internet Key Exchange) の概要 IKE Phase1 ネゴシエーションの詳細 IKE Phase2 ネゴシエーションの詳細 Remote Access 環境への対応 Remote Access の新たな手法 ~SSL VP

Transcription

1 I P s e c T10:Sec ~ 技術概要とセキュアなネットワークの実現手法 ~ 第一部 sec の基本とリモートアクセスへの応用 2003/12/3 新日鉄ソリューションズ株式会社基盤ソリューション事業部マーケティング部松島正明

2 Agenda sec の基本 IKE(Internet Internet Key Exchange) の概要 IKE Phase1 ネゴシエーションの詳細 IKE Phase2 ネゴシエーションの詳細 Remote Access 環境への対応 Remote Access の新たな手法 ~SSL VPN~ 2

3 sec の基本 3

4 VPN とは Virtual Private Network 仮想私設網 / 仮想自営網 Public なネットワークをあたかも私設 ( 自営 ) のネットワークのように使用するための技術 私設ネットワークに見せかけるために トンネリング技術を使用 VPN 暗号技術ではない Gateway_X Internet Gateway_Y Server_A データ B 宛 データ B 宛 Y 宛 X 宛 A 宛 データ A 宛 データ Client_B 4

5 sec( Security Protocol) sec とは にセキュリティ機能を持たせるためのプロトコル 暗号と鍵管理を分離して標準化 2 つのモードと 2 つの形式がある v4 と v6 の両方で使用可能な技術 セキュリティ機能 認証 鍵管理プロトコル (IKE IKE) の相互認証機能 sec 通信時の HMAC-MD5/HMAC MD5/HMAC-SHA1 による認証機能 改竄防止 sec 通信時の HMAC-MD5/HMAC MD5/HMAC-SHA1 による改竄防止機能 暗号 DES-CBC による暗号化 ( ほとんどが 3DES をサポート ) 5

6 2 つのモード トランスポートモード データ部分だけが暗号 / 認証の対象 トンネルモード 元の パケットに新たな を付加する 元の パケットすべてが暗号 / 認証の対象 暗号データ B 宛 SGW X 暗号データ B 宛 Y 宛 SGW Y Host A A 宛 暗号データ Host B X 宛 A 宛 暗号データ Host A Host B 6

7 2 つの AH(Authentication Header) RFC2402 Protocol No = 51 提供する機能 送信元の認証と データの完全性を確保 リプレイ攻撃防御機能 ( オプション ) もとパケットトランスホ ートモート トンネルモート 認証範囲 AH データ AH データ 認証情報 認証情報付加された データ 認証範囲 次番号ペイロード長予約セキュリティパラメータインデックス (SPI) シーケンス番号認証データ ( 可変長 :4 バイト整数倍 )

8 2 つの ESP(Encapsulating Security Payload) RFC2406 Protocol No = 50 提供する機能 データの機密性 ( 暗号 ) 送信元認証とデータの完全性を確保 リプレイ攻撃防御機能 セキュリティパラメータインデックス (SPI) シーケンス番号 I V ( 初期ベクトル ) もとパケットトランスホ ートモート データ ESP データ認証範囲暗号化情報 認証データ ペイロードデータ ( 可変長 ) パディング (0~255 バイト ) パディング長次番号 トンネルモート ESP データ認証範囲暗号化情報付加された 8 認証データ 認証データ ( 可変長 :4 バイト整数倍 )

9 リプレイ攻撃防御機能 リプレイ攻撃 通信内容を記録しておき あとで再生する攻撃 sec のリプレイ攻撃に対する機能 受信パケットのシーケンス番号を確認し 重複している場合は そのパケットを破棄 シーケンス番号の確認は リプレイ防御ウィンドウで行う シーケンス番号は 32bit 一巡した場合は SA を無効とする No:13 No:12 No:11 No:9 No:7 No:8 No:7 9

10 sec のセキュリティポリシー セキュリティポリシー パケットトラフィックに対し sec を適用するルールを定義 パケット破棄 (discard discard) パケット通過 (bypass bypass) sec 適用 (apply apply) セキュリティポリシーデータベース (SPD SPD) sec デバイスで設定されるセキュリティポリシーを格納するデータベース 送信用と受信用の 2 つのデータベースを使用する 10

11 sec のセキュリティポリシー セレクタ セキュリティポリシーを定義する情報 一般的には 送信元 宛先 プロトコル等を定義する セレクタ順序処理送信元宛先プロトコルトンネルモード http ESP / /24 https 3DES smtp HMAC-SHA1 3 Any Any Any bypass Internet SGWA SPD / /24 SGWA SGWB 11

12 Security Association Security Association(SA) 2 者間で sec 通信を実施する際に必要となる 暗号鍵情報や使用する暗号 認証アルゴリズム情報 sec の SA は送信用と受信用の SA がある SA には有効期限がある IKE が SA を確立する SPI(Security Security Parameter Index) SA を検索するための識別子 SAD(Security Security Association Database) 確立した SA を格納しておくデータベース 送信用と受信用の 2 つのデータベースを使用する 12

13 SA,SPI SPI,SAD SAD の関係 Initiator SGW A SAD SPI Life Time /ESP/SHA-1 SAD SPI Life Time /ESP/SHA-1 IKE SA Responde r SGW B SAD SPI Life Time /ESP/SHA-1 SAD SPI Life Time /ESP/SHA-1 暗号データ SPI:123 ー SPI:321 ー暗号データ 13

14 sec 処理の流れ ( 送信時 ) データ sec Policy SPD SPD Bypass Accept データ SAD IKE Peer SA SPI データ SA SAD SA 14

15 sec 処理の流れ ( 受信時 ) データ Accept 他の端末宛のパケットは転送 SPD SPD Accept 自分宛のパケットは上位層へ TCP/UDP sec SA SAD SA INVALID_SPI データ SPI SAD IKE 15

16 IKE(Internet Key Exchange) の概要 16

17 IKE の役割 IKE の提供する機能 認証 秘密鍵 (SA SA) を共有する相手を認証する 認証方式は下記の 4 種類 既知共有秘密鍵 (Pre Pre-Shared Secret Key) 認証方式 デジタル署名認証方式 公開鍵暗号認証方式 改良型公開鍵認証方式 SA の確立と管理 sec 通信に先立ち 秘密鍵 (SA SA) を確立する 有効期間を管理 ( 有効期間が切れる前に再度 SA 確立 ) 17

18 IKE の機能 Phase1 役割 ISAKAMP SA の確立 ISAKAMP SA の折衝 共有秘密鍵の生成 認証 Phase2(sec SA) を安全に生成するための通信路の確立 2 つのモード メインモード 計 6 回のメッセージ送受信で ISAKMP SA を確立 実装必須 アグレッシブモード 計 3 回のメッセージ送受信で ISAKMP SA を確立 実装はオプション 18

19 IKE の機能 Phase2 役割 sec SA の確立 セキュリティプロトコルの折衝 共有秘密鍵の生成 モードは 1 つ クイックモード 計 3 回のメッセージ送受信で sec SA を確立 19

20 IKE の動作 (Phase1 Phase1) Initiator SGW A IKE IKE Responder SGW B ID ID 20

21 IKE の動作 (Phase Phase2) Initiator SGW A ISAKMP SA Responder SGW B IN:123 Ack IN:321 OUT:321 暗号データ SPI:321 ー OUT:123 ー SPI:123 暗号データ 21

22 IKE Phase1 ネゴシエーションの詳細 22

23 パラメータ折衝 (Pre Pre-Shared Key) Initiator SGW A 3DES Hash SHA1 Pre-Sh DH 5 24H DES Hash MD5 Pre-Sh DH 1 24H IKE SA を確立するために使用するパラメータを提案 ( 複数提案可能 ) Responder SGW B 受入れたパラメータを回答 ( 複数回答不可 ) DES Hash MD5 Pre-Sh DH 1 24H 23

24 鍵材料の交換 (Pre Pre-Shared Key) Initiator SGW A DES Hash MD5 DES Hash MD5 Pre-Sh Pre-Sh DH 1 DH 1 24H 24H DH Nonce Responder SGW B DH Nonce Pre-Shared Key,DH 鍵情報, Nonce により共有鍵を作成 Pre-Shared Key,DH 鍵情報, Nonce により共有鍵を作成 24

25 認証 Ini Res (Pre Pre-Shared Key) SGW A IKE SA によって暗号化 SKEYID を作成 SKEYID=PRF(pre-shared secret key,ni Nr) 認証に使用される HASH_I HASH_I=PRF(SKEYID,g^i g^r CKY_I CKY_R SAp ID_I) ID HASH データ復号化した後 ID と HASH_I を取出す SGW B PRF: 疑似乱数関数 Ni:Initiator の Nonce 情報 /Nr:responder の Nonce 情報 g^xy:dh によって作成された共有鍵 g^i::initiator の DH 公開情報 /g^r:responder の DH 公開情報 CKY_I:Initiator のクッキー情報 /CKY_R:Responder のクッキー情報 SAp:SA ヘ イロート 情報 25 SKEYID を作成 SKEYID=PRF(pre-shared secret key,ni Nr) 認証に使用される HASH_I HASH_I=PRF(SKEYID,g^i g^r CKY_I CKY_R SAp ID_I) 受信した HASH_I と計算した HASH_I と一致したら 鍵交換と Initiator の認証が成功したことになる

26 認証 Res Ini (Pre-Shared Key) Initiator SGW A データ復号化した後 ID と HASH_I を取出す ID Hash Responder SGW B IKE SA によって暗号化 SKEYID を作成 SKEYID=PRF(pre-shared secret key,ni Nr) 認証に使用される HASH_I HASH_R=PRF(SKEYID,g^i g^r CKY_I CKY_R SAp ID_R) SKEYID を作成 SKEYID=PRF(pre-shared secret key,ni Nr) 認証に使用される HASH_I HASH_I=PRF(SKEYID,g^i g^r CKY_I CKY_R SAp ID_I) 受信した HASH_I と計算した HASH_I と一致したら 鍵交換と Responder の認証が成功したことになる 26 PRF: 疑似乱数関数 Ni:Initiator の Nonce 情報 /Nr:responder の Nonce 情報 g^xy:dh によって作成された共有鍵 g^i::initiator の DH 公開情報 /g^r:responder の DH 公開情報 CKY_I:Initiator のクッキー情報 /CKY_R:Responder のクッキー情報 SAp:SA ヘ イロート 情報

27 IKE Phase2 ネゴシエーションの詳細 27

28 パラメータ提案 Initiator SGW A IKE SA によって暗号化 SKEYID_d = PRF(SEYID, g^xy CKY-I CKY-R 0) SKEYID_a = PRF(SEYID, SKEYID_d g^xy CKY-I CKY-R 1) SKEYID_e = PRF(SEYID, SKEYID_a g^xy CKY-I CKY-R 2) Phase2 Stage1 HASH1 HASH1 = PRF (SKEYID_a, M-ID SA Ni [ KE ] [ IDci IDcr ] ) Responder SGW B 3DES SHA1 DH 5 8H DES MD5 DH 1 8H sec SA を確立するために使用するパラメータを提案 認証情報として HASH1 共有鍵作成のため DH 公開情報乱数情報も合わせて送信 28

29 パラメータ選択 SGW A IKE SA によって暗号化受信した Hash1 の認証確認 Phase2 Stage2 HASH2 Responder SGW B HASH1 = PRF (SKEYID_a, M-ID Ni SA Nr [ KE ] [ IDci IDcr ] ) 受入れたパラメータを回答 認証情報として HASH2 共有鍵作成のため DH 公開情報乱数情報も合わせて送信 DES MD5 DH 1 8H 29

30 sec SA の確立 Initiator SGW A 受信した Hash2 の認証確認 IKE SA によって暗号化 DES MD5 DES MD5 DH 1 DH 1 8H 8H Responder SGW B Phase2 Stage3 HASH3 HASH1 = PRF (SKEYID_a, 0 M-ID Ni Nr ) Initiator の生存証明のために Hash3 を送信 受信した Hash3 の認証確認 30

31 Remote Access 環境への対応 31

32 sec をリモートアクセス環境で使うと イントラネット 経路上の NAT VPN ゲートウェイ Internet VPN 通信 自宅 アドレス重複 Mail Server File Server Web Server DNS Server サーバファーム ユーザ認証 32 公衆無線 LAN サービス

33 sec をリモートアクセス環境で使うと 検討すべき問題点 認証に関する問題 リモートユーザを認証するためのしくみ NAT に関する問題 多くの公衆無線 LAN サービスは Private アドレスのため 経路上に NAT 機器が介在する アドレスに関する問題 Private アドレスの重複 フラグメントに関する問題 VPN ゲートウェイでフラグメント化されたパケットが VPN クライアントまで到達しない 33

34 認証に関する問題 問題点 1 ゲートウェイ間の sec 通信で最も使用されている Main モードで Pre-Shared 認証を使用する方法はリモートクライアントでは使用できない 原因 Main モードの Pre-Shared では 認証の際に通信相手の アドレス情報を使用する リモートクライアントは アドレスを固定できないため Main モードの Pre-Shared は使用できない ID HASH アドレス 34 リモートホストの アドレスは変化するので認証では使えない

35 認証に関する問題 解決策 ユーザ情報 Aggressive モードを使用する ID 情報に アドレスを使用しなくても良い ID 情報にユーザ情報を使用し 既知共有鍵にユーザのパスワードを使用する事が出来る IKE ID IKE ID HASH IKE ID HASH 35 認証に アドレスを使用しないからリモートアクセスに対応できるんだ HASH 計算時にユーザのパスワードを使用

36 認証に関する問題 解決策電子署名認証方式 リモートクライアント ハッシュの計算に公開鍵を使用 ID ID 証明書所有者など VPN ゲートウェイ CA 受信した証明書の有効性確認 認証に P アドレスを使用しないからリモートアクセスに対応できるんだ ID 情報に証明書所有者などの情報を送信するため ユーザを特定する事が可能となる ID 情報と証明書を受信すると証明書の有効性確認を行う 36

37 認証に関する問題 問題点 2 sec は基本的に リモートユーザを認証する機能を持っていない 対応策 XAUTH または Hybrid Auth をサポートした製品を使用する XAUTH,Hybrid Hybrid Auth とも Internet Draft から Expire ただし 多くの sec 機器および Client ソフトは XAUTH をサポートしている Hybrid Auth をサポートしている製品は少数 XAUTH,Hyblid Hyblid Auth ともに Radius,One Time Password, S/Key などが使用可能 37

38 認証に関する問題 ~XAUTH 使用時のネコ シエーション ~ リモートクライアント VPN ゲートウェイ Vendor ID クライアントは =0x DFD6B712 XAUTH サポートだ!! IKE SA Radius サーバ ユーザ名 / Password 要求 ユーザ名 :hoge Passwd : abc123 認証 OK ACK sec SA 38

39 NAT に関する問題 問題点 AH は が認証範囲に入っているため NAT には対応できない ESP は のすぐ後に ESP があるため NAPT(Network Network Address Port Translation) に対応できない (1 対 1 の NAT には対応可能 ) トランスホ ートモート AH 認証範囲 データ認証情報 ESP データ認証範囲 認証データ トンネルモート AH データ認証範囲 ESP データ認証範囲 認証データ AH は が認証範囲にふくまれるから NAT がダメなんだ ESP のトンネルモート は 直後に ESP が来るから NAT がダメなんだ 39

40 NAT に関する問題 解決策 NAT Traversal(NAT NAT-T) をサポート製品を使用する イニシエータは NAT-D ペイロードに始点 アドレス / ポート番号 終点 アドレス / ポート番号を埋め込んで送信する レスポンダは NAT-D ペイロードの中のデータと実際の アドレス ポートを比較して NAT の有無を検知する 送信元 アドレス 宛先 アドレス 送信元ポート番号 宛先ポート番号 UDP ISAKMP KE Ni NAT-D NAT-D sec パケットは UDP Encapsulation of sec Packet で UDP Encapsulation される NAT-T のドラフトバージョンが異なると NAT-T 対応製品同士でも接続は不可能 ( 要注意!!) 40

41 NAT に関する問題 NAT Traversal(NAT NAT-T) リモートクライアント IKE SA sec SA SA UDP(500,500) Vendor ID = draf aft-ietf ietf-ipsrc ipsrc-nat nat-t-ike ike-03 KE UDP(500,500) NAT NAT-D (Source & Port) NAT NAT-D (Destination & Port) ID UDP(4500,4500) [CERT],SIG Phase2 ネゴシエーション N A T デバイス VPN ゲートウェイ クライアントは NAT-T サポートだ!! SA UDP(500, x) x Vendor ID = draft ft-ietf ietf-ipsrc ipsrc-nat nat-t-ike ike-03 NAT-D ペイロードで NAT の有無を確認 KE UDP(500, x) x NAT NAT-D (Source & Port) NAT NAT-D (Destination & Port) ID UDP(4500,Y) [CERT],SIG Phase2 ネゴシエーション 認証データ データ ESP 41 Non-IKE マーカ UDP

42 アドレスに関する問題 問題点 リモートアクセスユーザのアドレスと 社内のネットワークの重複 リモートアクセスユーザ Aとリモートアクセスユーザ B ユーザのアドレスの重複 どちらのユーザに返すべき??? User A VPN ゲートウェイ Server イントラネット User B

43 アドレスに関する問題 外部の DNS サーバを参照してしまう 内部のサーバのアドレスを解決できない 無線スポット A Intranet.hoge.co.jp の アドレスは? VPN ゲートウェイ 社内 DNS Server Server イントラネット 43 外部 DNS Server そんな名前は知らないよ

44 アドレスに関する問題 解決策 Server VPN ゲートウェイから VPN 通信用の アドレスを割当てる sec-dhcp または ISAKMP Configuration Method をサポートする製品を使用する 発信元 : 発信元 : 宛先 :GW アト レス宛先 : ESP データ User A Interface: Virtual : VPN DNS: DNS Server /24 イントラネット ネゴシエーション時に sec 通信で使用する アト レス等が割当て User B Interface: Virtual : VPN DNS:

45 アドレスに関する問題 sec-dhcp 2003 年 1 月 RFC 3456 で標準化 Phase2 で DHCP 用の SA を確立する VPN ゲートウェイリモートクライアント IKE SA DHCP SA ID= /UDP/67 ID=GW アト レス /UDP/68 DHCP Request sec-dhcp で割当てられた アト レスデータ sec SA ESP DHCP Reply Internal-v4-Address = x.x.x.x Internal-v4-Netmask = 24bit Internal-v4-DNS = y.y.y.y HotSpot で割当てられた アト レス 45

46 フラグメントに関する問題 フラグメントに関する問題 Ethernet Ethernet+sec sec 使用により 等の情報追加で MTU を越える可能性が高くなる HotSpot では ADSL が多く使用されているので PPPoE 等の追加もあるので 更にフラグメントが発生し易い状態になる 14B Ether 14B Ether 46~ B データ 4B FCS 46~ B 最大 20B 16B 257B 12B ESP ESP 認証データトレーラデータ 4B FCS Ethernet + sec + PPPoE 14B Ether 6B PPPoE 2B PPP 46~ B 最大 20B 16B 257B 12B ESP ESP 認証データトレーラデータ 4B FCS 46

47 フラグメントに関する問題 Server DNS Server /24 イントラネット PMTU を送信できるか? HSD MTU=1500B PMTU 1500B DF=1( パケット分割不可 ) の場合は パケットを破棄して 送信元に PMTU を送信する データ DF=1 の場合パケットの破棄 PMTU 送信 1000B データ ADSL MTU=1454B フラグメント発生 DF=0 の場合 データ データ DF=0( パケット分割可 ) の場合はパケットを分割して送信する 47

48 フラグメントに関する問題 Server DNS Server / B データ 1000B データ MTU=1000 =1000B データ データ フラグメントされたパケットが通過しない データ イントラネット DF=0( パケット分割可 ) の場合でも 経路中に 1 台でもフラグメントしたパケットを通過させられない機器があると クライアント側からみると通信不能状態となる フラグメントされたパケットが届かない為 パケットを再構築する事ができない 48

49 フラグメントに関する問題 解決策 サーバ側の MTU サイズを調整する 経験では 1380B 程度に設定すればフラグメントによる通信障害の大半は回避できる データ 1380B 1000B データ フラグメントされたパケットが通過しない機器 MTU=1454 =1454B DNS Server /24 イントラネット データ ESP 1453B データ ESP フラグメントされないから パケットは通過 49

50 フラグメントに関する問題 解決策 DF=1 にして PMTU をと通すようにする MTU=1454 =1454B MTU=1200 =1200B PMTU ESP DF=1 データ 送信パケット破棄 MTU of next hop 1453B 1127B PMTU 送信 フラグメントされたパケットが通過しない機器 イントラネット MTU of next hop :1200B データ ESP 1200B 50

51 リモートアクセス使用時のまとめ VPN 構築において留意すべき点 認証は何を使うか?XAUTH や Hybrid Auth に対応しているか? NAT-Traversal Traversal に対応しているか? sec-dhcp に対応しているか? 経路上に IKE をふさぐようなデバイスがないか フラグメントが起きて通信できないような場合は予めサーバ側の MTU を小さくしておく また ICMP の PMTU を通すようにしておく クライアントのデスクトップセキュリティ ウイルスその他の攻撃に遭った場合 それをそのまま会社に持ち込む可能性も考えられる 51

52 Remote Access の新たな手法 ~ SSL VPN ~ 52

53 SSL とは? Secure Socket Layer TCP 通信を安全に行うための機能を提供 暗号化 :RC4,DES などの暗号機能 相互認証 : 通信する相手を認証する機能 メッセージ認証 : 通信中のデータ改竄を検知する機能 実装はアプリケーションに依存する アプリケーション アプリケーション アプリケーション SSL SSL の API TCP Ethernet など 53

54 SSL VPN SSL VPN とは? SSL を利用して VPN を実現する技術 基本的には SSL 技術とリバースプロキシ技術の組合せで VPN を実現する 2 認証画面が表示され認証情報を入力 1SSL VPN にアクセス 3 ポータル表示されたアクセス可能なリソースから任意のリソースを選択 4 SSL VPN ゲートウェイが代理でサーバにアクセス 54

55 非 SSL アプリへの対応 リバースプロキシー方式 WEB ブラウザだけを使用してアクセスする 多くの製品は WEB と Windows ファイル共有が使用可能 ポートフォワード方式 Java アプレットをダウンロードし 社内リソースへの通信を SSL 化して転送する TCP 固定ポートのアプリケーションが使用可能 SSL トンネル方式 専用クライアントを使用して 社内リソースへの通信を SSL 化して転送する TCP/UDP 問わずほとんどのアプリケーション使用可能 55

56 ポートフォワード方式 1 ポータルから非 SSL 対応アプリを選択 2 Java アプレットを自動的にダウンロードし起動する 3 Java はポートフォワード機能と 選択されたサーバのアドレスを hosts ファイルに追加する 4 選択したリソースへのアクセスを開始すると hosts ファイル参照により クライアント自身 (Java が受取る ) 宛に通信を行う 4 社内リソース宛の通信を受信した Java は通信を SSL 化して SSL VPN ゲートウェイに転送 56

57 SSL トンネル方式 1 ポータルから非 SSL 対応アプリを選択 2 初めての場合は ActiveX で自動的にクライアントアプリケーションをインストール 3 クライアントアプリケーションにより仮想インターフェースが設定される 4 選択したリソースへのアクセスを開始すると その通信は仮想ドライバが SSL 化し SSL VPN ゲートウェイに転送する SSL VPN ゲートウェイのアドレス 目的サーバのアドレス Src Dst TCP Src Dst Data クライアントのアドレス 仮想 IF のアドレス SSL による暗号化 SSL トンネル時のパケットの構成 57

58 SSL VPN 導入の注意点 社内に居る時と 社外に居るときで操作が変わる すべてのリソースをポータル経由でアクセス メール本文記述の URL や クライアント PC のブックマークを使用して直接リソースにアクセスできない クライアントアプリケーション クライアントアプリケーションがインストールされる際には Administrator 権限が必要となる 証明書の検証 クライアント証明書の検証が行われない製品が多い SSL の標準では証明書の検証が行われないため SSL VPN ゲートウェイの実装も証明書の失効検証が行われない製品が多い アクセス制御について アクセス制御の設定変更が有効になるタイミングが製品によって異なる 製品によっては アクセス制御の設定変更時に全てのセッションが切断されることがある 58

59 sec vs SSL VPN 対応端末 OS 依存 sec 対応アプリケーション 上で稼動するアプリケーション製品依存 使い勝手 ネットワーク環境依存 アクセス制御 費用 リソースへのアクセスはローカル環境と同様のオペレーションで可能 NAT-T や sec-dhcp でほぼ解決しているが MTU 問題が若干残る アドレス単位で実施 小規模の場合 SSL VPN より割安大規模の場合 SSL VPN より割高になる可能性が高い SSL VPN SSL 対応 WEBブラウザが稼動すればプラットフォームに依存しない 携帯電話やPDAもOK リソースへのアクセスはポータル経由 NAT や名前解決の問題は発生しない リソース単位で実施 ( 例えば URL 単位やフォルダ単位 ) 小規模の場合 sec VPN より割高大規模の場合 sec VPN より割安になる可能性が高い 現状では 使用したい端末とアプリケーションとのバランスを考慮して VPN 技術を選択することが 失敗しないリモートアクセス VPN に繋がる 59

60 ありがとうございました 商標について 本文記載の会社名および製品名は それぞれ各社の商標又は登録商標です 60