2023年5月5日金曜日

ローカルハードウェア vs. クラウド

コンピュータリソースを オンプレミスからクラウドに移す流れの中で、従来、ローカル接続していたハードウェア(周辺機器)の一部も仮想化、実体をクラウドに置くようになった。

クラウドはコンピュータを仮想化して提供している。画面で構成を指定すればコンピュータが起動する。停止も画面から行う。クラウドのネットワーク構築も画面上でマウス/キーボードで行える。コンピュータ設置、OSインストール、ネットワーク設定、スイッチ、ルータの設置、ケーブル接続する作業をしたことがあれば、この仮想化がどれだけ便利か実感できる。

そのような実体験をしていると、なんでも仮想化してしまえば便利ではないか、という考えを抱くようになっても不思議ではない。実際にやってみると、それでうまくいってしまうようだ。

秘密鍵を保管する HSM(ハードウェアセキュリティモジュール)は、従来コンピュータに直接接続されたスマートカード(ハードウェア)に保管するしかなかった。現在は、クラウド化された HSM が利用できる。HSMを利用するプログラムは、HSMがどこにあっても関係なく操作できる。クラウド化された HSMは、 ユーザにとってハードウェアーを持っている必要はない。

弊社はソフトウェア保護ドングル( Matrix ) を扱っている。このドングルをクラウド化したものが vMatrix ( https://www.ribig.co.jp/vmatrix ) である。プログラムは Matrix APIを呼びだすが、APIはローカル接続の Matrixドングルを操作するのではなく、クラウドコンピュータとやり取りをする。原理は HSM クラウド化と同じ。

クラウド化したソリューションは、通常は問題なく動作する。問題はネットワークやクラウドコンピュータにトラブルが発生したときだ。ネットワーク/クラウドコンピュータのトラブルは発生するものとして、どれだけの期間継続するのかが問題になる。クラウドとは違うが、以前、サーバをレンタルしていた。ある日突然停止。どんなに長くても数時間で復旧すると思っていたが、最終的に3日ほどつかえなかった。国内にあると思っていたデータセンターが国外にあり、データセンタの火災が原因だった。何が起こるのか分からない。

不測の事態への対応方法はいろいろあろうが、ローカル接続のハードウェアでも動作するようにしておくことが最終的な解決方法ではないかと思う。となると、ローカル接続のハードウェアを常時使った方が良いことになる。


Pkcs#11 API

 マイナンバーカード関連記事を見ていると、既存ツールを使って操作していることが多いいようだ。Pkcs#11 を呼びだすようなプログラムを作成する例はあまり見かけない。

1.  Pkcs#11を使う機会が少ないー>使う開発者が少ない

2.  Pkcs#11 の仕様は英語。しかし、人気がないので日本語化されない。

3. 既存ツールでなんとか間に合ってしまう

4. Windows では別のAPIが用意されている

などが理由ではなかろうか。

メーカ依存しないスマートカードを操作する標準 API なので、 マイナンバーカードのようなスマートカードをいじるには重宝するはずだ。ただし、保存するデータ(証明書、鍵)の詳細を知らなければならないため、ある程度本格的に取り組む必要がある。このデータの扱いが面倒なことが、既存ツールを使う理由の1つでもあろう。

メーカ依存しないAPIという位置づけだが、実際には細かな違いがあるようだ。プログラム本体を変更せずに、Pkcs11モジュールを差し替えただけで、別のスマートカードが操作できたことはない。Pkcs11仕様は緩いため、解釈によって実装は異なる。モジュール/スマートカード毎の対応が必要なことがある。

スマートカード(トークン)メーカは必要最小限のツールは添付するが、あとは pkcs11 モジュールを使ってユーザ自身でやりたいことを実現してね、という提供方法をしている。スマートカード(トークン)に詳しいユーザは自由で扱えるだろうが、それ以外では使いこなすまでかなり手間がかかる。リビッグでは、 スマートカードトークンmTokenをトークンをすぐに使えるように専用ツールを用意、トークン入手後すぐに使えるはずである。

マニュアル https://www.ribig.co.jp/mtoken/download/pki_util.pdf

FireFox はかなり前から Pkcs#11 を組み込んでいた。スマートカードを操作するためでなく、秘密鍵のファイルへの保存を Pkcs#11 でやっていた。その Pkcs#11 は受け取ったコマンドでスマートカード操作ではなくファイル操作をしていた。当初は秘密鍵をスマートカードに保存するつもりだったのだが、誰もがスマートカードを持っているわけではないため、ファイルをバックエンドとして使うことにしたのではないかと思う。

最近は AWS などでクラウドが Pkcs#11のバックエンドとして使われている。プログラムによるPkcs#11 APIを呼びだしが、ライブラリによりクラウドに対して行われる。ローカルに接続したスマートカードではなく、クラウド上のリモートコンピュータにコマンドが送られて、そのリモートコンピュータが処理した結果が返されるという仕組みである。この方法だと、秘密鍵が別ハードウェア(リモートコンピュータ)に置かれるため、スマートカードとセキュリティ的に同等になる。

Pkcs11では秘密鍵を格納した(仮想)デバイス(スマートカード、リモートコンピュータ、ファイル)から取り出さずに暗号/復号が行える。Pkcs11 はスマートカードを操作するのではなく、スマートカードの機能(秘密鍵のセキュアな管理)を操作する API というのが正確になるだろう。マイナンバーカードを操作するというとハッキングを連想させるかもしれないが、マイナンバーカード(スマートカード)本来の機能を呼びだしているにすぎない。その結果を悪用するとハッキングになる。

プログラムから見ると同じ API、つまり、同じように操作できるのだが、コマンドが送られる先が、ローカル接続のハードウェアであるとレガシーと呼ばれ、クラウドであると時流にのっていると最近では呼ばれる。これは、ローカルハードかクラウドかという問題になるため、別の記事で取り上げたい。



2023年5月4日木曜日

マイナンバーカードでWindowsアプリケーションにコード署名(Windows版)

Windows の 実行ファイルがアンチウィルスソフトによって感染していると誤検出されることがある。メジャーなアンチウィルスソフトは、実行ファイルにコード署名を見つけると誤検出しないようだ。

コード署名にはコード署名証明書が必要だ。有名どころのCAから取得すれば、コード署名するだけで、署名したEXEの出所は CA が証明してくれる。

独自CAを立てて、そのCAが発行した署名用証明書でコード署名するという手もあるが、”おれおれ”CAなので、署名したEXEの出所を自身で証明しているだけだ。コード署名した実行ファイルを渡す相手と直接やりとりがあり、相手が実行ファイルの出所がわかっていれば、特に実行ファイルの出所は問題にならないだろう。このような場合、”おれおれ”コード署名は、アンチウィルスソフトによって感染していると誤検出されること避ける目的だけに利用するときにはつかえるだろう。

”有名どころのCA”、”独自CA”の他に、マイナンバーカードの署名用証明書でコード署名する方法も可能なようだ。

マイナンバーカードでWindowsアプリケーションにコード署名をする

 https://qiita.com/binzume/items/3c09a7f2434e6c4478d9

JPKI 認証局(CA) が発行した個人がだれかを証明する証明書で、コード署名することになる。証明書内の個人情報(生年月日など)がコード署名した実行ファイルに含まれることになる。また、JPKI 認証局(CA) は事前に Windows の信頼されたルート証明機関には登録されていない。JPKI利用者ソフトなどをインストールすると登録される。

上の記事では Linux でコード署名。試してみると、カードリーダを Linux でうまく認識しない。やはり、ハードウェア接続がからんでくると、ほとんどの機種が対応しているのは Windows になる。そこで記事と同じ方法を Windows で試してみた。

結論からいうと Windows 64ビット版でいまくいった。osslsigncode は32ビット版としてビルドできなかった。

必要なバイナリを収めたZIPファイル

https://www.ribig.co.jp/personal/morikawa/myna-code-sign.zip

ZIPに含まれるPDFファイルに簡単な説明の記載がある。

感想としては、上の記事でのべられているのと同じになる。

マイナンバーカードの構造をしったり、どのように PKI 応用ができるか検証作業をするのが目的であれば、試してみる価値があると思う。



2015年5月25日月曜日

Amazon AMI にAmavid-new を導入してみた

CentOS の Postfixメールサーバにウイルススキャンとスパムフィルタリング機能追加のため amavisd-new と Clamav を同時にインストールしていました。標準のレポジトリーに amavisd-new と Clamav のどちらも提供されているためyum install でどちらも簡単にインストールできました。

Amazon AMI では、そのままで Postfix + amavisd-new + Clamav 構成のメールサーバは導入はできません。標準のレポジトリーに amavisd-new の提供がありません。Clamav は提供されていて、以下 URL などで分かりやすく導入に関する資料が載っています。

http://www.agilegroup.co.jp/technote/ec2-clamav.html

epel リポジトリを追加すれば yum で amavisd-new もインストールできるようになるようですが、いままで yum でインストールしたことしかなく amavisd-new をインストールすることでどのようなファイルがどこに配置され、どのような設定がされるのかよく分かりません。そのためepel レポジトリからインストールした amavisd-new で問題が起きないか心配です。

そこで amavisd-new (amavisd-new-2.10.1.tar.xz)をプロジェクトのメインサイト

http://www.ijs.si/software/amavisd/ 

からダウンロードして手動インストールしてみました。

[
このブロッグを投稿してからしばらくして、以下 URL のページを見つけました。よくわかっている方のページなので参考になるとおもいます

http://linux.yebisu.jp/memo/765
]


ダウンロードして最初に分かったことは、Postfix 用には2つのファイルしか必要ないということです。 (amavisd 本体と 設定ファイルamavisd.conf) amavisd は Perl で書かれたプログラムで、いくつかの Perlモジュールに依存しているようです 。Perlと依存モジュールがあれば amavisd は動作しそうです。

1. Perl をインストール

2. INSTALL ファイルに記載されている依存モジュールをインストール

Archive::Zip   (Archive-Zip-x.xx) (1.14 or later, currently 1.30)
Compress::Zlib (Compress-Zlib-x.xx) (1.35 or later, currently 2.060)
Compress::Raw::Zlib (Compress-Raw-Zlib) (2.017 or later)
MIME::Base64   (MIME-Base64-x.xx)
MIME::Parser   (MIME-Tools-x.xxxx) (currently 5.504)
Mail::Internet (MailTools-1.58 or later have workarounds for Perl 5.8.0 bugs)
Net::Server    (Net-Server-x.xx) (version 2.0 adds support for IPv6)
Digest::MD5    (Digest-MD5-x.xx) (2.22 or later)
Time::HiRes    (Time-HiRes-x.xx) (1.49 or later)
Unix::Syslog   (Unix-Syslog-x.xxx)
Mail::DKIM     (Mail-DKIM-0.31 or later, currently 0.40)

>perl –MCPAN –e shell
>install [モジュール名]

3. オプションとなっている Mail::Spamassassin モジュールをインストールしようとしましたがエラーになってしまいます。代わりに yum で spamassassinをインストールしました。

これで amavisd の実行環境は整ったはずですが、amavisd はどのように起動するのでしょうか。ダウンロード済のファイルに amavisd-init.sh がありました。とりあえず開いてみると "/usr/sbin/amavisd"(19行名), "/etc/amavisd.conf"(22行目)となっています。amavisd 本体は /usr/sbin に、設定ファイルは /etc にコピーしておけば、amavisd-init.sh で起動できそうです。

シェルスクリプトを /etc/init.d に amavisd という名前でコピーしてから、chkconfig –add でサービス登録、最後に/sbin/service amavisd start で起動できるはずですが、起動前に /etc/amavis.conf を確認しておきます。

17/18行目に起動ユーザ名/グループの指定があります。

17行 $daemon_user  = 'vscan';     # (no default;  customary: vscan or amavis), -u
18行 $daemon_group = 'vscan';     # (no default;  customary: vscan or amavis), -g

以下の行のコメントは外しました。

22行  $MYHOME = '/var/amavis';

32行 $db_home   = "$MYHOME/db";      # dir for bdb nanny/cache/snmp databases, -D
33行 $helpers_home = "$MYHOME/var";  # working directory for SpamAssassin, -S
34行 $lock_file = "$MYHOME/var/amavisd.lock";  # -L
35行 $pid_file  = "$MYHOME/var/amavisd.pid";   # -P

ユーザ/グループの既定値はないようです。いままで amavis というユーザ、グループ名を使っていたため、vscanをamavis に変更。まだ、Linux にamavisというグループとユーザがないため、amavis グループとユーザをログイン不能(-s /sbin/nologin)として作成しました。ホームディレクトリは /var/amavis にしました。

これで起動できそうです。amavis サービスをスタートすると、エラーが表示されました。必要なディレクトリが存在しないようです。/etc/amavisd.conf を見ると 36行目に

#NOTE: create directories $MYHOME/tmp, $MYHOME/var, $MYHOME/db manually

とあります。$MYHOME = '/var/amavis' ですので /var/amavis/tmp, /var/amavis/var, var/amavis/db ディレクトリを作成してから、ディレクトリのオーナーとグループをamavis に変更後、再度サービスをスタートさせてみました。起動しました。停止もできました。

Clamav との連携も amavis.conf の 383-386行のコメントを外して387-391行の Note の通りに設定すれば問題ないようです。

まだ確認したわけではありませんが、amavisd-new のインストールは Perl関連モジュール導入するだけなので epel レポジトリからインストールしても問題はなさそうです。インストール後の amavis.conf の$daemon_user、$daemon_groupとソケットファイル名を確認すれば Clamavとの連携も問題はないのではないでしょうか。

INSTALLファイル43-49行に外部プログラム(解凍用)に関する記述があります。

The following external programs are used for decoding/dearchiving
if they are available:
  compress, gzip, bzip2, nomarch (or arc), lha, arj (or unarj), rar (or unrar),
  unzoo (or zoo), pax, cpio, lzop, freeze (or unfreeze or melt), ripole,
  tnef, cabextract.
Self-extracting archives (executables) can be of types zip, rar, lha or arj,
and are only recognized when the corresponding dearchiver is available.

レポジトリから amavisd-new を Yum でインストールすると、これらのプログラムもインストールされるはずです。しかし、Amazon AMI ではrar, ripole, tnef などを別途導入しないとログに必要な外部プログラムが存在しないと書き込まれてしまいました。Amazon AMI 標準のレポでは提供されていないようなので、ログをみて必要な解凍プログラムを rpmforge から導入しました。

インストールが完了後に INSTALLファイルの下の方にインストール方法に関する説明が
あることを発見しました。わざわざ手動インストールしたので、ここに記載されている手順にしたがってインストールしたら amavis についてよくわからないままになっていたはずです。amavis.conf ファイルを見ながら(試行錯誤しながら)導入したおかげで いままでより amavis がよく分かった様な気がします。

備考:

いままでAmavisd の重要な設定について以下URLの解説が役に立ちました。amavisd と PostfixやClamav と連携する方法の説明は見かけますが、ウィルス感染したファイルが添付されていると判断されメールや、スパムと判断されたりしたメールをどう扱うかの設定についての説明はあまり見かけません。このページでは virus, spam, bad headerメールをどのように処理するのかの設定を説明しています。

http://www200.pair.com/mecham/spam/amavisd-settings.html



2015年5月16日土曜日

Windows/OSX/Linux でのHIDデバイスの抜き差し検知

1. Windows

何もしなくても HIDデバイスの抜き差しで、ウィンドウプロシージャに WM_DEVICECHANGE メッセージが投げられてきます。何もしなければ、デバイスを差すと複数の WM_DEVICECHANGEメッセージが発生します。抜いた時も複数のメッセージが発生する場合があります。

確実に抜き差しで1回の WM_DEVICECHANGEメッセージが発生するようにするには、このURLが参考になります。

http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-or-Removal


2. OSX

検知する デバイスの ID を登録しておき、そのデバイスの抜き差し操作があったら呼び出される関数を登録しておきます。そのデバイスが抜き差しされたら OS が登録した関数を呼び出します。差し込みの時、抜き取りの時と別々に呼び出す関数を登録できます。IOKitが必要です。

Windowsと比較すると、セットアップ処理をするコードを追加しなければなりませんが、細かな制御ができます。


 HID デバイスの抜き差し検知は安定しています。


3 Linux

Windows/OSX のようにプログラム内で HID デバイスの検知する方法を知りません。そのようは方法があるかどうかも分かりません。

udev ルールで HIDデバイスの抜き差し操作があったときに実行されるプログラムを登録できますので、そのようなプログラムを作成して、そのプログラムとアプリケーションプログラム本体とがプロセス間通信をして検知した HID デバイス情報は受け渡したり、抜き差しイベントを発生させたりすることができます。

udev ルールでプログラムを実行させる設定については、

http://www.reactivated.net/writing_udev_rules.html

のページ内の Running external programs upon certain events を参照してみてください。

抜き差しを検知するルールをセットアップ、抜き差しで実行させるコードを指定するというモデルは OSX とまったく同じですが、 OSX ではすべてがライブラリで統合されていて、アプリケーションプログラムの1つのスレッドでデバイス検知が可能です。一方 Linux はそのような統合はされておらず、それぞれのコンポーネントを手動でつなぎ合わせなければなりません。


カスタム Credential Provider の開発


Windows Vista以降の OS のログインは従来の GINA方式 から Credential Provider 方式になっています。

1. GINA では、GINA DLL からエクスポートする関数が決められていて、その関数を実装しました。

2. GINA 方式では、カスタム GINAがすべてを機能を実現することは不可能でした。 Windows 標準の msgina に依存しなければならない機能があり、エクスポート関数から msgina 内の同じエクスポート関数を呼び出す必要がありました

3. CP は COM になりました。Windows 標準の CP に依存することなく、カスタム CP ですべての機能を実装できるようになりました。


カスタム CP は、マイクロソフト提供の CP サンプルをもとに作成することが推奨されてます。

このブログと同じタイトルの Japan Platform SDK Support Team Blog の記事が以下 URL にあります。

http://blogs.msdn.com/b/japan_platform_sdkwindows_sdk_support_team_blog/archive/2011/04/22/credential-provider.aspx

この記事の内容を参考にしながら、CP サンプルをカスタマイズして独自 CP を開発していくことになるはずです。

弊社では CP サンプルをもとに MxLogon / GAuthLogon を作成していますが、1つ教訓を得ました。それは、CP のサンプルのコードは鵜呑みにしない、コードを確認しないまま使わないで、どのような処理をしているのか、そして、それが正しく処理されているかをある程度確認てから使うようにしないと、最後までバグに悩まされるということです。

Web には CPサンプルのバグが指摘している記事がいくつか見つかります。どこにも書かれていない問題点も存在するようです。

カスタム CP 作成のできるだけ早い段階で CP サンプルコードを確認することを勧めたいと思います。

CP V1 / V2 の2つのバージョンがありますが、V2 を先に開発すると V1 は V2のコードに V1/V2専用のコードを define 追加することで、容易に1つのコードベースから V1/V2 のどちらでも生成できるようになると思われます。

MxLogon は USBキーを利用した CP でUSBキーの抜き差しを検知して動作を決めます。ハードウェアの抜き差しを検知して動きを変える CP 開発は、ハードウェアと使わない CP と比較すると格段に難しくなるという印象があります。 その理由の1つは、CP が同時に2つ実行されることがあるからだと思います。サンプルのコードは同じ CP が同時に複数実行されることを想定していないようなので、カスタム CP ではそれを想定してカスタマイズする必要があります。

最初はソフトだけで完結する フルCP から作成して、その後ハードウェアを使う CP に手をつけたほうが、長期的には早道になるような気がします。

2015年5月13日水曜日

AWS で Windows サーバを立ててみる

現在まで10年ほど使ってきた Windows 2003 Server 用 PC は、頻繁につかっていたのではないので、まだ健在だ。過去数年は数か月に1度程度しか電源を入れていない。電源を投入すると大きなファンの音が鳴り響き、しばらくすると熱を放ち始める。さすがに真冬は暖房代わりとはいかないが、秋、春の肌寒い季節に起動しておくと、狭い部屋は暖かく感じる。夏は耐えられない。そして、何よりも耳に触るのがファン音だ。しばらく使ってから電源を落とすと、辺りに静寂が戻り、精神的にホッとする。このようなことから、電源を入れないで済むように環境を整備して、とりあえずなんとかなった。

騒音の出ないサーバがあれば便利だと思っていましたが、最近はAWS でサーバを立ち上げるというオプションもあります。サービスとしてサーバがクラウド上にあれば、熱や音で悩まされることはないはずだと思い、AWS で 社内用にWindowsサーバを立ち上げてみました。

なにしたいかというと、社内 LAN 上に AWSの Windowsサーバがあるかのような環境を整えることができるかどうか、そして、そのよう環境を実運用できるかどうかを確かめることです。

1. 社内 LAN と VPC間をVPN接続

AWS の VPN はIPsecなので IPsec対応の VPN装置が必要です。簡単に試せるような装置をさがしていたところ、

https://ultradairen.wordpress.com/2013/12/22/buffalo-vr-s1000-vpn-to-aws/
Buffalo VR-S1000 VPN to AWS

を見つけました。バッファロー VR-S1000 は実売価格 20,000円で、インターネットルーター機能、10接続VPN, 簡易NAS( USBポートに接続した USBメモリ/ハードディスクを共有できる ) といった機能を兼ね備えています。これを使って試してみました。


2.  AWS で Windows 2012 Server R2 (無料枠対象)インスタンスを作成


最初は何も考えずに Windows 2012 Server R2 のEC2 インスタンスを 作成してみました。物理的な作業はまったく不要で、身体を動かす必要がありません。OSインストールも不要です。
このインスタンスは VPC ( 10.0.0.0/16 )の サブネット 10.0.0.0/24 に配置したものとします。


3. VPC へのVPN 接続


この VPC に VR-S1000を使って接続してみます。

3-1  AWS側設定


a. カスタマーゲートウェイ作成 
社内インターネット接続の WAN IP アドレスを指定するのみで作成できます。

b. VPNゲートウェイ作成/アタッチ。
任意の識別名を指定するだけで作成できます。作成したら、VPC ( 10.0.0.0/16 ) にアタッチします。

c. VPN接続作成
カスタマーゲートウェイとVPNゲートウェイを指定して VPN 接続を作成します。ルーティングは”静的”を選択して、 VR-S1000 の LAN側アドレス ( 例えば 192.168.10.0/24 ) を指定します。

d. セキュリティ設定の追加
インバウンドルールで 送信元 192.168.10.0/24からのトラフィック、プロトコール, ポートを許可します。


3-2  VR-S1000 の設定


a. AWSコンソール - VPC - VPN接続で、作成済みの VPN接続を選択して "設定のダウンロード”で Microsoft - Windows Server の設定を取得します。

b. VPN ウィザードで ”事前共有キー”に Preshared keyの値、”リモートWAN IPアドレス”に
Remote Tunnel Endpointの値、リモート LANネットワークに 10.0.0.0, リモート LANサブネットマスクに 255.255.0.0 を設定して、[追加]します。次の画面で暗号化方式を AES-128 に変更します(2箇所)


3-3 設定確認


インスタンスのプライベート IP ( ここでは10.0.0.100 ) に対して PING して応答が返ってきました。次にリモートデスクトップでこのインスタンスに接続していました。AWSコンソールの EC2から Windows 2012R2のインスタンスを選択して、[接続]ボタンで 

a. リモートデスクトップファイルのダウンロード
b. Administrator ユーザのパスワード取得

をします。ダウンロードしたリモートデスクトップファイルをダブルクリックして RDP 接続を開始。ユーザ名(Administrator)とパスワードを設定して Windows にログインできました。


4 問題点

この Windowsサーバはデフォルトの VPCのサブネットで動いています。デフォルト VPCは、特に何もしなくてもインターネットゲートウェイが付いていため、インターネット接続ができるようになってます。インスタンスに Elastic IP が割り当てられていれば、そのパブリック IPでインターネットアクセスができますし、外部からこのインスタンスにアクセスできます。これは、社内 LANのサーバに外部からそのサーバの パブリック IP でアクセスできてしまうことを意味します。

これでは困ります。社内 LAN 上のサーバのように、プライベート IP だけを持っていて、外部には自由に NAT 経由で出ていくことができる一方、外部からはアクセスできないようにしなければなりません。


5. NATインスタンス


そのようは方法を探すと、AWS サイトにNATインスタンスというものが紹介されていました。

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html#NATSG"
NATインスタンス


a. デフォルト VPC とは別途 VPC を作成して、そこに2つのサブネットを作成。

b. インターネットゲートウェイを この新規 VPC にアタッチ

c. 1つのサブネットのルートテーブルでデフォルトゲートウェイにインターネットゲートウェイを指定
してパブリックサブネットとする

d. このパブリックサブネットに NATインスタンスを立ち上げる

e. もう1つのサブネットのデフォルトゲートウェイに NATインスタンスを指定。外部へは直接アクセスするルートはないため、プライベートサブネットになる

f. Windowsサーバをこのプライベートサブネットに配置する

g. この VPC に VPNゲートウェイをアタッチして Windows サーバに RDP 接続を行う


思っていたより簡単に Windows サーバをプライベートサブネットに配置できました。NATインスタンス専用の AMI があります。NATインスタンスは本当に起動するだけで、ログインする必要すらありません。ローカル LAN にブロードバンドルータを取り付けるといった感覚で設置できました。もちろん、LANケーブル、電源コードをいじる必要はなく、ブローバンドルータの既定 IP アドレスが分からないといったこともなく、AWSコンソールからすべて設定できました。

サブネットを複数作成してもルータを設置する必要がありません。ルータは”組み込まれている”
そうです。インターネット回線を用意する必要もありません。机に座ったままキーボードとマウス操作だけでインターネット接続できる複数のサブネットをもったネットワークにサーバを立てて、VPN接続できる環境を整えることができてしまいました。Windowsサーバに言語パックをインターネットから導入したときにインターネット接続が非常に速かったことに気づきました。

6. Windowsサーバ使用

Windowsサーバは北米リージョンで立ち上げました。既定では言語は英語になっていましたので、日本に変更しようとしてみると、ディスク容量不足でインストールできませんでした。無料枠は 30GBの容量でインスタンスが作成されていましたが、インスタンス作成直後、1GB程しか空き容量が残っていませんでした。これでは何もできないため、現在のボリュームのスナップショットを作成してから、ボリュームを削除、新規に 50GB の EBS ボリュームをスナップショットをもとに作成しました。


この新規ボリュームをインスタンスにアタッチして、インスタンスを起動しても C ドライブのサイズは以前のままです。 管理ツールの「コンピュータ管理」ー「ディスク管理」を使って Cドライブを拡張しました。

Cドライブの容量が 50GB になったところで、Windowsの言語を日本に変更してみたところ問題なく変更できました。

次に AWS の Windows サーバから社内 LAN 側のリソースを参照できるかどうか確認してみました。エクスプローラで \\(社内PCのIP) を指定すると、アクセスのためのユーザ情報が求められたあと、共有フォルダにアクセスできました。社内 LAN上のプリンタも問題なくセットアップでき、Windows サーバから直接印刷ができました。ほとんど遅延なく、北米のWindowsサーバから社内プリンタに印刷がされました。

おそらく社内 LAN に置いた物理サーバを置き換えることができるような気がします。


7  物理サーバ利用との比較


AWS の Windowsサーバは短期間の一時的な利用であればメリットは十分あると思われます。短期間の利用のために、わざわざ PC購入、設置、 OS インストールする必要はなく、使った分の費用しかからないため、費用的なメリットも十分にあるはずです。しかし、長期間にわたって使うことは零細企業にとってはコストメリットを十分に検討する必要があるような気がします。

AWS 費用は非常に細かく設定されていて、トータルのコストは1つ1つ積み上げてみないと分かりません。

a. EC2
b. EBS
c. Elastic IP
d. VPN接続

EC2 は停止可能、Elastic IP はデタッチ可能ですが、EBS は一度使い始めたら削除できません。VPN接続も、削除/作成を繰り返すわけにいきません。 EBS / VPN 接続は24時間/365日課金されるはずです( VPN接続を作成した時点から課金されると理解しています)

多くても数台のサーバが必要なだけの零細企業が業務に使うことことを考えると、すぐに飛びついて利用できるものではないのかもしれません。

AWS は、大手企業がオンプレミスのサーバ群を AWS に移すことができる環境を構築できるようなので、中途半端な部分はないはずです。すべてが”本格的” といった印象があります。クラウドサービスでもっとも気になるのがセキュリティだと思いますが、こちらも”本格的”のようです。

http://yoshidashingo.hatenablog.com/entry/2014/08/24/211825

このような本格的なインフラのコストだと考えると納得できる価格だとは思いますが、従来そこまで本格的なインフラを構築してきていない零細企業にとってはコスト負担増加は避けられないのではないでしょうか。

業務ではなく、提供する製品やサービスに利用する目的で AWSを活用する機会は零細企業にもあるはずですので、ハード/OS一切自前で用意することなくテスト、評価、試用目的で一時的に活用するメリットは十分にあるのではないかと思われます。

AWS ですぐに利用開始できたのは Route 53 DNSサービスでした。他のサービスとの違いは、ヘルスチェック機能が付加されている点で、この機能をつかうだけでもメリットはあるのではないかと思っています。

8  レンタルサーバとの比較

AWS でレンタル専用サーバと同じことをすることを考えると、コスト増は避けられません。インスタンスをハード占有にすると、1時間2ドルの追加料金(年 $2 x 24 x 365 = $17,520? ) が発生するようです。ハード占有にしない、リザーブドインスタンスにする、といったことで同等コストで Webサーバを構築できるかもしれません。同等コストで可用性、信頼性、保守性が高まるのであればメリットがでてきます。

可用性を求められる場合、本サーバ、バックアップサーバの2つのインスタンスを起動しておき、Route 53 DNSサービスでフェイルオーバを利用する、本サーバとバックアップサーバ間でデータの同期の問題がなければバックアップサーバは普段は止めておき本サーバに異常が発生したら通知を受け取り起動するなど、柔軟に考えた通りの構成を実現できそうです。

9 サービス提供のインフラとしての利用

AWS を使うことで零細企業でも大手と同じインフラを使ってサービスが提供できるようになります。サービスの可用性、安定性、信頼性について、AWSを使うことで”大手を同じインフラをつかっています、同等の可用性、安定性、信頼性です”といった形で提示できるメリットは大きいと思います。