卒業論文セキュアなBYOD環境を実現するシンクライアントサーバ制御

卒業論文
セキュアなBYOD環境を実現する
シンクライアントサーバ制御技術の研究
指導
村山純一教授
東海大学情報通信学部
通信ネットワーク工学科
1BJT1115
八代理紗
概要
近年、個人所有端末の増加に伴いビジネス面で個人端末を利用するBYODに注目が集まって
いる。BYODを導入するにあたり、セキュリティ面の脆弱性からシンクライアントを同時に導入する
場合が一般化されている。そして、シンクライアントシステムの普及・発展に伴い高度処理の必要
なアプリケーションを実行できるようにすることが想定される。そのときユーザ数の増加や高度処理
の実行からシンクライアントサーバを実行する物理サーバにCPU負荷がかかってしまうことが懸念
される。
そのため、本論文では仮想PC方式シンクライアントシステムを利用したシステム構成を想定して、
実行による負荷を可能な限り抑えつつ、CPU負荷の減少をさせるにはどのようにライブマイグレー
ション (仮想PCを実行したまま、物理サーバ間を移動させること)をすればいいかの検証を行った。
その結果、ライブマイグレーションは並列処理するとCPU負荷が高くなってしまい向いていないこと
がわかった。また、容量による変化が得られず今回の実験条件においてはどの容量からマイグレ
ーションさせても構わないということがわかった。
2
目次
目次
第 1 章序論
1.1 背景
1.2 目的
第 2 章システム構成
2.1 シンクライアント
2.1.1 サーバーベース型
2.1.2 ブレード PC 型
2.1.3 仮想 PC 型
2.2 前提システム構成
2.3 BYOD サーバのマイグレーション
第 3 章実験
3.1 実験条件
3.2 実験方法
3.3 実験結果
第 4 章結論
第5章
まとめ
謝辞
参考文献
付録
3
第１章
1.2
序論
背景
近年、個人端末所有率の増加により企業情報通信ネットワークへの Bring Your Own
Device(BYOD)導入の試みが活発化している。BYOD 導入の利点としてはコスト低減化や BCP
対策、利便性の向上などがあげられる。
一方で、端末管理がユーザ主体となるため、端末の誤操作、紛失・盗難やマルウェア、
ウイルスなどによって情報漏えいしてしまうセキュリティ面の脆弱性が懸念されている
[1][2]。
そのため BYOD 端末に対するセキュリティ対策として Mobile Device Management(MDM)や
Network Access Control(NAC)など様々な手法の企業側から端末管理を行うアプリケーショ
ンが流通している[3]が端末のプライバシー問題が侵害される恐れがある。そこで端末から
の影響を受けにくい、シンクライアント[4][5]が流通している。
1.2
目的
シンクライアントでは端末側の処理は簡素化される一方で、サーバ側の処理は複雑化す
る。またシンクライアント技術の発展により従来向いていないとされていた処理の多い動
画などのアプリケーションも実行できるようになってきている。そこで BYOD サーバを仮想
化し物理サーバに収容させ、その際の物理サーバの負荷削減技術を確立することを目的と
する。
4
第2章
2.1
システム構成
シンクライアント
シンクライアントにはネットワークブート型と画面転送型の 2 つの種類がある。ネット
ワークブート型とはシステムドライブをネットワーク上に置いて、ブートすることで利用
することができるシンクライアントシステムである。ネットワークブート型ではクライア
ント起動時に大量のトラフィックが流れることや動作環境がクライアントの性能によって
差ができてしまうため今回のシステムには不向きと判断した。
次に画面転送型についてはサーバーベース型、ブレード PC 型、仮想 PC 型の 3 種類があ
る。画面転送型はクライアントから操作情報しか送信されないため標的型攻撃などのウイ
ルスにも強いと想定される。そこで前述の 3 つについて詳しく説明する。
2.1.1
サーバーベース型
まずサーバーベース型は本来クライアント上で実行するアプリケーションをサーバ上で
実行させ、クライアント側から操作情報を送信し、その実行結果画面をクライアントに表
示することで実行できるシンクライアントシステムである。アプリケーションは複数のク
ライアントで共有されるため更新やメンテナンス作業が 1 回で済む。また、シンクライア
ントシステムとして一番普及しており実績が一番多い。
ただし、複数のクライアントが 1 台のサーバを共有するため、構築時のサーバ設計で詳
細が必要になり設計よりも通信クライアントや CPU 使用率が増えてしまうと可用性に問題
が出てくる可能性が高い。またアプリケーションも共有となるためマルチユーザ対応のア
プリケーション以外使用することができない。
2.1.2
ブレード PC 型
次にブレード PC 型は 1 クライアントに対しブレード PC という板状の PC を１台使用する
ことで利用できるシンクライアントシステムである。ブレード PC が通常の PC と同じ動作
をするためユーザの自由度が高く、アプリケーションに厳しい制約がかかることもない。
また、1 台ずつが別 PC として成り立っているため他のユーザによる干渉を受けることもな
く、障害が発生した場合も該当 PC のみ停止することができる。
しかし、共有システムではなくなるため正確に利用者数を見積もり、ブレード PC を用意
しないといけない。また PC が増えるという認識のため管理システムの負担がサーバーベー
ス型に比べると増えてしまう。
5
2.1.3
仮想 PC 型
仮想 PC 型はサーバーベース方式と同じように複数のクライアントに対し１台のサーバ
が接続する。ただし、クライアント数に対してサーバ上に仮想的に複数の PC を作り、クラ
イアントは仮想 PC に接続する。そのためアプリケーションに対するユーザ同士の干渉は起
こらない。また仮想 PC であるため障害が起きた場合にも冗長性が高く、クライアント数の
増減にも対応しやすい。代表的なものとして Horizon [6]や Xen Desktop[7]などがあげら
れる。
ただ、管理者は従来のサーバ運営の知識とは別に仮想 PC に対する知識が必要となってし
まうため初期導入に対する負担が増えてしまう。
2.2
前提システム構成
今回の研究で想定するシンクライアントしては前節で上げたことを基軸として考え、ユ
ーザ数に対する伸縮性、ユーザ同士の干渉等を考え仮想 PC 型方式を採択する。次の図は今
回の前提システム構成である。
BYOD クライアントはインターネットを通して企業情報通信ネットワーク内にある物理サ
ーバに接続する。物理サーバ上には各 BYOD クライアントに対応した仮想 PC である BYOD サ
ーバが立ててある。BYOD サーバからは企業情報ネットワーク上にあるため従来の企業内ホ
スト群と同じように企業内サーバ群にアクセスすることができる。ただし、アクセスする
BYOD サーバが特定の物理サーバ上で集中してしまうと実行速度が急激に低下する可能性が
ある。そこで BYOD サーバは物理サーバ間をライブマイグレーションさせることでサービス
中断せずに移動し、負荷分散させる。
6
2.3
BYOD サーバのマイグレーション
今回 BYOD サーバは仮想 PC 型を採択しているため、マイグレーション機能の実装が可能
になる。従来の PC とは違い、仮想 PC はソフトウェアであるため、同じ環境の仮想 PC を作
るのが非常に容易である。その為マイグレーションというネットワークを利用することで
物理サーバ間移動することも容易にできる。また今回はサービス中断を最低限で抑えるシ
ステムであることも必要であるため、マイグレーション機能の中でもライブマイグレーシ
ョン機能を利用する。ライブマイグレーションとは通常のマイグレーションとは違い、該
当仮想 PC を停止させることなく物理サーバ間移動させる機能のことである。
しかし、ライブマイグレーション自体も実行することで物理サーバの処理負荷を高める
という問題がある。したがって BYOD サーバをどの様な順序や重み付きにして実行するかが
重要課題となる。
7
第3章
実験
今回の実験では各物理サーバの様子を把握しつつ、分散処理を行う管理サーバがどのタ
イミングで実行させるか基本データを収集する。そのために管理サーバとしてシステム構
成とは別の物理サーバを用意する。
3.1
実験条件
下の表は今回の実験における条件である。
機能
物理サーバ
BYOD サーバ
BYOD クライアント
シンクライアントソフト
通信インタフェース
マイグレーション機能
実装
CentOS、6.5、2 個
Devian、wheezy
Devian、wheezy
VNC
100Base-T
kvm のライブマイグレーション
また、各物理サーバには kvm のライブマイグレーションを実行するための前提条件のた
め SSH を立て管理サーバからの指示で実行できるように java と sh のプログラミングを動
かすことで両方向にライブマイグレーションする。また今回は物理サーバの負荷計測のた
め BYOD サーバと BYOD クライアントは実験により個数を変更している。
3.2
実験方法
実験方法としては、まず物理サーバ上がそれぞれ ssh 接続できるようにして kvm のライ
ブマイグレーションを行う。この時ライブマイグレーションを行う条件を並列処理か、逐
次処理かで変更する。また BYOD サーバの容量を変更しどのように重み付けすればいいかを
検討する際に利用する。また各物理サーバの負荷がどのくらいかかっているかは「sar」コ
マンドを実行前に起動し 1 秒ごとに表示させ、各 10 回ずつ計測した。
3.3
実験結果
まず逐次処理と並列処理で実行した場合は送信側の結果がグラフ 1 と 2、受信側の結果
が 3 と 4 のようになる。左のグラフが逐次処理した場合で右のグラフが並列処理した場合
の結果を表している。逐次処理は 1GB の仮想 PC を 1 台のみマイグレーションをした場合、
並列処理は 1GB を 3 台同時にマイグレーションした場合である。グラフの縦時間は各項目
の負荷率をパーセンテージで表し、横軸は経過時間を表している。また今回のデータでは
外れ値があった場合に備えて経過時間ごとの最大値を外し、2 番目の最大値を取り出すこ
とで CPU 負荷率の想定最大値を抽出する。
8
グラフ 1：送信側 1 台の場合
グラフ 2：送信側 3 台の場合
グラフ 3：受信側 1 台の場合
グラフ 4：受信側 3 台の場合
各グラフのデータは青い線がユーザの操作による動作の CPU 稼働率、赤い線がシステム
が自動的にする動作の CPU 稼働率、緑の線が CPU 全体の待機率を 100 から引くことで算出
した CPU 稼働率である。
まず送信側の結果を見ると 1 台の場合最大で 9 秒かかっていたものが 3 台を並列処理す
ると 21 秒で処理が終了するので 9 秒を 3 倍にすると 27 秒であるため約 5 秒ほど時間短縮
が出来た。また CPU の処理としてはユーザ使用率とシステム稼働率は上昇があったものの
そこまでの変化が起きなかった。稼働率は 1 台の場合 50 パーセント以下だったのに対して
3 台並列処理するとほぼ 100 パーセントの状態になった。
次に受信側の結果を見るとユーザ使用率はそこまで変化が起きなかったが、システム稼
働率は 2 倍近くに上がり、稼働率も送信側ほど長い時間ではないが 90 パーセントを超える
時間が出来てしまうということが分かった。
続いて仮想 PC の容量による変化を見るために容量を 1GB、4GB、8GB で変えて 1 台ずつマ
イグレーションさせた場合の結果が次のようになる。グラフ 5,6,7 が送信側の CPU 負荷で
8,9,10 が受信側の負荷を表している。グラフの縦軸は CPU の負荷率、横軸は経過時間を表
している。左上のグラフが 1GB の場合、右上が 4GB の場合、下が 8GB の場合のグラフであ
る。
9
グラフ 5：送信側 1GB の場合
グラフ 6：送信側 4GB の場合
グラフ 7：送信側 8GB の場合
グラフのデータは青がユーザ使用率、赤がシステム使用率、緑が稼働率である。まず経
過時間はどの容量に相手も 6 秒から 9 秒ほどでマイグレーションを完了させた。またグラ
フをみて分かるようにユーザ使用率、システム使用率はどの容量においても最大値にほぼ
変化がなかった。稼働率は 8GB の場合にのみ数秒グラフが飛び出るがそこまでの変化は得
られなかった。
10
次のグラフは受信側のグラフである。左上が 1GB、右上が 4GB、下が 8GB の場合のグラフ
である。
グラフ 8：受信側 1GB の場合
グラフ 9：受信側 4GB の場合
グラフ 10：受信側 8GB の場合
受信側のグラフを見るとユーザ使用率に変化は現れなかった。4GB の場合のみシステム
使用率と稼働率に若干の上昇が見られたが、8GB の場合と 1GB の場合にほぼ変化がなかっ
た。
11
第4章
結論
今回の実験では逐次処理、並列処理の場合の CPU の負荷率の変化と仮想 PC の容量による
CPU 負荷率の変化について実験、計測を行った。
まず、逐次処理と並列処理を比較した場合だが、逐次処理で 1 台を動かした場合に比べ
て並列処理で 3 台を同時に動かした方が 1 台あたりの処理時間が短くなる。しかし、並列
処理をした場合送信側では CPU 稼動率が 1 台のものに比べて著しく上昇してしまいほぼ 100
パーセントになってしまう、受信側では CPU 使用率がほぼ 100 パーセントに加えてシステ
ム使用率も 2 倍以上に膨れ上がってしまった。そのため今回の実験よりさらに多くの仮想
PC をマイグレーションさせることになる企業ネットワークではさらに CPU 負荷が増大して
しまうことが考えられる。今回の想定システム構成ではマイグレーションすることによっ
て物理サーバの負荷を下げることが目的のため、実行による負荷が大きくなる方法では意
味をなさなくなってしまう。つまり並列処理は今回の想定システム構成には向いていない
ということがわかる。
次に仮想 PC の容量を変化させてマイグレーションさせた場合では、送信受信共に若干の
負荷率の上昇が見られるものの特出した変化を得られなかった。この結果からマイグレー
ション機能は仮想 PC の容量による影響を受けないということがわかる。ただ、ライブマイ
グレーションの特性として差分書き換えを何度も実行することで仮想 PC を実行したまま
移動させる。それに対して今回の実験では BYOD クライアントからの入力をしていなかった
ため、差分がほぼ生まれず書き換え量がどの容量でも同じくらいになったため変化による
影響を受けなかったということが考えられる。
12
第5章
まとめ
今回の想定システム構成では BYOD を利用することを前提としたシンイアントシステム
を組み込んだシステムを想定した。シンクライアントシステムは今回のシステムでの利点
が多いことから仮想 PC 方式を採択した。
BYOD ではユーザ数の伸縮性が必要であること、シンクライアントシステムでの高度処理
を行う作業の増加が考えられるため、物理サーバの負荷分散をどう実行するかが問題であ
る。そこで仮想 PC 方式を有効に利用した機能としてライブマイグレーションを利用しどの
ように実行するかがポイントとなっていた。そこでこの研究ではどのように実行するかの
基礎データを習得した。
実験の結果、実行時間は短縮できるものの CPU に負荷がかかってしまうため並列処理は
向いておらず逐次処理で実行した場合どの容量で実行したとしても時間、CPU 負荷共に問
題ないという結果が得られた。
しかし、容量による変化が見られなかった要因として仮想 PC 上でアプリケーションを実
行していなかったことやライブマイグレーションの動作が差分書き換えであることが考え
られるため、今後クライアントがアプリケーションを利用している場合やネットワークを
利用している場合などによる CPU 負荷状況や容量による変化が得られるのかなどが重要課
題となる。
13
謝辞
本研究を進めるにあたり熱心にご指導いただいた村山先生に感謝いたします。
様々なアドバイスをいただいた村山研究室の皆様、
4 年間様々な知識をご教授いただきお世話になった学科の先生方に感謝いたします。
参考文献
[1]”スマートフォン＆タブレットの業務利用に関するセキュリティガイドライン,”
日本スマートフォンセキュリティフォーラム(JSSEC),2012
[2] Eun Byol Koh, Joohyung Oh, and Chaete Im, A Study on Security Threats and Dynamic
Access Control Technology for BYOD, Smart-work Environment, IMECS 2014
[3] Rivera, David; George, Geethu; Peter, Prathap; Muralidharan, Sahithya; Khanum,
Sumaya, Analysis of security controls for BYOD, 2013
[4]Sinclir, J. and Merkow, M.: Thin Clients Clearly Explained, Morgan Kaufmann,
San Francisco (2000).
[5] Niraj Tolia， David G Andersen ， and M ．Satyanarayanan ， ”Quanitifying
Interactive User Experience on Thin Clients ，
t’IEEE Computer ，Mar ．2006 ， pp ．46 −52
[6] VMware Inc. Horizon. http://www.vmware.com/jp/products/horizon-view/ 2014
[7] Citrix Systems Inc. XenDesktop.
http://www.citrix.co.jp/products/xendesktop/overview.html/ 2014
14
付録
管理サーバで実行する待機 java プログラミング
import
import
import
import
import
import
import
import
import
import
import
import
import
import
java.net.*;
java.io.*;
java.io.File;
java.io.FileWriter;
java.io.BufferedWriter;
java.io.PrintWriter;
java.io.IOException;
java.util.*;
java.text.*;
java.sql.Connection;
java.sql.DriverManager;
java.sql.ResultSet;
java.sql.PreparedStatement;
java.sql.SQLException;
public class office{
public static void main(String[] args) throws Exception{{
Connection conn = null;
PreparedStatement ps = null;
PreparedStatement ps2 = null;
ResultSet rs = null;
String[] echosp = null;
// データベースへ接続するための設定
String path = "jdbc:mysql://localhost/relay_db"; //接続パス
String id = "root";
//ログイン ID
String pw = "passwd"; //ログインパスワード
//SQL 文を定義する
String sql = "UPDATE user SET server = ?, date = ?, time = ? WHERE host = ?";
String sql3 = "INSERT INTO user values(?, ?, ?, ?, ?)";
String count = "select count(*) from user";//行数カウント
String sql2 = "SELECT * FROM user";
try{
Class.forName("org.gjt.mm.mysql.Driver");// ドライバクラスをロード
conn = DriverManager.getConnection(path, id, pw);
//DB へのコネクションを作成する
conn.setAutoCommit(false); //オートコミットはオフ
try {
ServerSocket server = new ServerSocket(1); //クライアントからの接続待機
15
InetAddress.getLocalHost());
while(true) {
Socket connect = server.accept();
BufferedReader in = new BufferedReader(new
InputStreamReader(connect.getInputStream()));
OutputStreamWriter out = new
OutputStreamWriter(connect.getOutputStream());
while(true) {
String echo = in.readLine();
if (echo == null || echo.equals("")) break;
echosp = echo.split(",");//文字の分割
System.out.println(echo);
out.write(echo + '\n');
out.flush();
}
//実行する SQL 文とパラメータを指定
ps = conn.prepareStatement(sql);
ps.setString(1, echosp[0]);
ps.setString(2, echosp[2]);
ps.setString(3, echosp[3]);
ps.setString(4, echosp[1]);
//UPDATE 文を実行する
int i = ps.executeUpdate()
//処理件数を表示する
if(i < 1){
//実行する SQL 文とパラメータを指定する
ps = conn.prepareStatement(sql3);
ps.setString(1, echosp[0]);
ps.setString(2, echosp[1]);
ps.setString(3, echosp[2]);
ps.setString(4, echosp[3]);p
s.setString(5, "check");
//INSERT 文を実行する
int j = ps.executeUpdate();
}
//コミット
conn.commit();
connect.close();
}
}
catch(Exception err) {
System.out.println(err);
16
}
}catch(Exception ex){
//例外発生時の処理
conn.rollback();
//ロールバックする
ex.printStackTrace(); //エラー内容をコンソールに出力する
}finally{
//クローズ処理
if(ps != null) ps.close();
if(conn != null) conn.close();
}
}}
}
物理サーバ上で実行する java プログラミング
import java.net.*;
import java.io.*;
import java.util.*;
import java.text.*;
import java.net.InetAddress;
public class client{
public static void main(String args[]) {
//Time
Date date1 = new Date();
SimpleDateFormat sdf1 = new SimpleDateFormat("yyyy/MM/dd");
TimeZone tz2 = TimeZone.getTimeZone("Asia/Tokyo");
Calendar cal2 = Calendar.getInstance(tz2);
String ip="";
try {
Socket sock = new Socket("192.168.1.11", 1);
BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
BufferedReader in = new BufferedReader(new
InputStreamReader(sock.getInputStream()));
PrintWriter out = new PrintWriter(sock.getOutputStream());
String time = cal2.get(Calendar.HOUR_OF_DAY) + ":";
if(cal2.get(Calendar.MINUTE) < 10){
time = time + "0"+ cal2.get(Calendar.MINUTE);
}else{
time = time + cal2.get(Calendar.MINUTE);
}
out.write(args[1]+","+ args[0] +","+sdf1.format(date1)+ "," +time+ '\n');
out.flush();
17
String msg = in.readLine();
sock.close();
}
catch(Exception err) {
System.out.println(err);
}
}
}
管理サーバ上のシェルスクリプト(引数として送信先 ip 受信先 ip 物理サーバ名
想 PC 名が必要)
#!/bin/bash
# ログイン情報を入力
send_ip=$1
recv_ip=$2
servername=$3
hostname=$4
username=root
password=passwd
java client $hostname $recv_ip
# expect コマンドを実行
expect -c "
# タイムアウト値の指定
set timeout 10
# spawn で新しいジョブ生成
spawn ssh -l $username $send_ip
# login
expect password:
send \"$password\n\"
sleep 1;
send \"sh /home/$servername/test.sh $recv_ip $hostname\n\"
sleep 15;
send \"exit\n\"
# spawn ジョブを通常の通信にする
interact
"
18
仮
物理サーバ上のシェルスクリプト(ホームフォルダに設置)
#!/bin/bash
# ログイン情報を入力
recv_ip=$1
hostname=$2
password=passwd
# expect コマンドを実行
expect -c "
# タイムアウト値の指定
set timeout 20
# spawn で新しいジョブ生成
spawn virsh migrate --live $hostname qemu+ssh://$recv_ip/system
# login
expect password:
send \"$password\n\"
# spawn ジョブを通常の通信にする
interact
"
19

Download Report