atone オンカジk8 カジノSSL-VPN、アプリケーション連携の先にあるもの仮想通貨カジノパチンコfifa fixtures

k888vip 07/27/2023 0 Comments

atone オンカジk8 カジノSSL-VPN、アプリケーション連携の先にあるもの仮想通貨カジノパチンコfifa fixtures

ビットコイン金比較k8 カジノ

ホームスロット伊丹　前編「なぜSSL-VPNなのか。素朴な疑問を解決しよう」ではSSL-VPNが登場するに至った背景や基本的な方式や、VPNのチャネルはどう作られるかという視点で説明した。今回はセキュリティという視点から説明を始めたい。その後で、SSL-VPNを使うと、いま使っているアプリケーションの利用がどう変わるかを説明する。

意外と多くの仮説を信じてセキュリティは実行、管理されているものだ■SSLを使わないリモートアクセスをまず考えてみる

　皆さんが、自宅からADSLを使ってインターネットを利用するとき、セキュリティが何も実行されていないわけではないだろう。PCにログインするときユーザーIDとパスワードを入力するし、契約プロバイダのネットワークにアクセスするとき、そのためのユーザーIDとパスワードを入力している。

　PC上ではパーソナルファイアウォールやウイルスチェックプログラムが常時動いているし、ブロードバンドルータでは、送受信するIPパケットを監視している。このようなユーザーは誰でも、企業のDMZから公開されているWebサーバの情報を閲覧できる。Webサーバに対しては、ページの改ざんが行われないように、Webブラウザを通じて、DMZのどこかで監視プログラムが走っているだろう。

　リモートアクセスを考えるとき、どのようなユーザーであってもこの程度のセキュリティ管理は行われているのである。もう1ステップ奥深く進んで、企業のイントラネットの中までアクセスを受け入れると、これまでできなかったリモートVPNが実現されることになる。ところが、この最後の1ステップが考えているよりはるかに難しく、克服すべき課題も多い。また、DMZ上のサーバにアクセスするときに適用されているセキュリティ基準をそのままリモートVPNに適用することはできない。

■セキュリティ実行結果の間で信頼関係の連鎖ができていない

　まず図を見ていただきたい（図1）。歴史的に、セキュリティはいつもそのとき必要とされる目的を満たすために単独で実現されてきた。その目的以上のことを実装することも難しい。例えば、PCにログインするとき、プロバイダにアクセスするときなど、ユーザーは最低でもIDとパスワードを入力している。この作業で、大多数のユーザーは、そのPCでアプリケーションを使うなら、これらの認証結果が使われていろいろなところへのアクセスが許されるだろうと思うかもしれない。実際には、これらの認証結果がほかから参照されることはまずない。

図1　独立に実行されているセキュリティユーザー自身ではID／パスワード（PCにログイン、プロバイダネットにログイン）　−アプリケーションを使うためではない PC上の監視ではあて先ポート番号でアクセス管理、あて先IPアドレスを監視　−誰が、どのアプリケーションを使っているかは不明ネットワーク上の監視ではIPアドレスを見るが、NATが入ってユーザーPCのIPアドレスは不明　−誰が、どのPCから、どのアプリケーションを使っているかは不明ファイアウォール上の監視ではアクセス先IPアドレスかポート番号でアクセス管理　−誰が、どのPCから、どのアプリケーションを使っているかは不明サーバ上の監視ではファイアウォールがあるのでどんなアクセスでも信用する　−内部からか外部からか分からない。誰が、どのPCから、どのアプリケーションを使っているかは不明アプリケーションではアプリケーションプロトコルでユーザーを確認する途中の情報はほとんど何も引き継がれない

　PC上ではパーソナルファイアウォールが使われており、送り出すIPパケット、届けられたIPパケットを監視している。ファイアウォールなので、IPアドレスやポート番号は見ても、どのユーザーがどのアプリケーションを使っているかという管理は行っていない。ユーザーがプロバイダへアクセスするときに入力したIDやパスワードは、IPパケットで送られたデータにすぎず、これらが取り出されて使われることもない。

　似たようなことはプロバイダで行う管理に関してもいえる。プロバイダのアクセスポイントでユーザー認証をしても、以降のアクセス管理には、プロバイダがPCに対して割り振ったIPアドレスが使われる。そこでは、IPパケットでアクセス管理、トラフィック管理を行うために、認証したユーザーに割り当てたIPアドレスに認証結果を引き継がせている。リモートアクセスサーバで一般的に行われる手法である。

　企業のDMZにIPパケットが届くときには、何度かNATが実行されて送り手IPアドレスは隠れてしまう。IPパケットを見てもユーザーのPCは分からない。多くはどこかのプロバイダのIPアドレスになっているはずである。こういう条件では、DMZで公開するWebサーバやメールサーバへのアクセスを管理するために、送り手IPアドレスでフィルタを掛けても意味がないことは容易に理解できるだろう。DMZ上のサーバへのアクセスになると、ファイウォールには、「これらサーバのIPアドレスとポート番号へのアクセスを許す」という管理しかできないのである。

　これはいい換えると、DMZにサーバを置く限り、常時監視は行えても、最初のアクセスだけは誰からのものであっても受け付けなければならない。IPアドレスには匿名性が出て、アクセスに使っているPCは分からない。逆の観点からは、サーバ環境にセキュリティ脆弱性が残っている限り、セキュリティの脅威から逃れることはできない、といえるのである。

　イントラネット上のサーバになると、すべてのアクセスがイントラネットのどこかから行われたようにしか見えない。もし、ファイアウォール経由でインターネットからのアクセスが行われると、特別なセキュリティ管理をサーバで、特定のアクセスに限定してだけ行うことは難しい。

　こういうDMZ上のサーバだけでなく、イントラネットのサーバへも安全にアクセスを許そうという目的を満たすのがSSL-VPNである。まず、こういうゲートウェイが満たすべき条件を整理しよう。

■VPNに使われるゲートウェイが満たすべき要件

　それぞれ、以下のようなチェック項目を用いて、管理していただきたい。いずれも、セキュアなSSL-VPNの管理に不可欠な項目である。

（1）セキュアなユーザー管理

リモートアクセスしてくるユーザーの本人確認を行う本人確認に使うユーザー情報を安全に管理するゲートウェイ運用者のアクセス権を安全に管理する

（2）セキュアなセッション管理

ユーザーからゲートウェイへのセッション、ゲートウェイからアプリケーションサーバへのセッションの間で受け渡されるデータが、改残されたり漏えいしたりしないよう安全に管理される一定時間アイドル状態が続いたセッションは切るなどの管理が行われるアプリケーションプロトコルの動作を壊さない

（3）セキュアなアプリケーション管理

使わせるアプリケーションを限定できるアプリケーションの起動条件をサーバ側で設定、変更できる

（4）セキュアなシステム管理

OS、システム環境が要さい化されているセキュリティパッチがすぐ適用できるようになっている不必要なサービスを起動していない