社内システムをつくろう!

社内システムをつくろう!

あるシステム担当のブログ。本サイトのご利用は自己責任にてお願い致します。

今年の秋は「ITサービスマネージャ試験」を受けようと思う。

どうも!

 

今年の秋の情報処理技術者試験は、ITサービスマネージャ試験を受けようと思っています。現在、高度試験資格としては、

  • ネットワークスペシャリスト
  • セキュリティスペシャリスト

の2つの資格を持っています。

 

本当はデータベーススペシャリストを受けたいのですが、残念ながら春季試験しかないんですね。セキュリティスペシャリストみたいに春秋両方でやってくれたら良いのですが…。

 

よく「資格試験は意味ない!普段の仕事に集中したほうが効率が良い」と言われますが僕はその意見に対しては懐疑的です。

仕事に関係ない資格を取りまくることについては、意味がないと思いますが、エンジニアが自分の関係する分野に関して資格試験の勉強をするのは意味のあることだと思うのです。

 

資格試験の学習を通じて、その分野を体系的に学ぶ事ができます。その分野が仕事に直結していれば勉強していて「なるほど!あれはこういうことだったのか」という瞬間が必ずあるはずです。

さらにその周辺の知識も学習することができて、より深い知識を得ることもできます。普段の仕事に活かせることも多々あるはずです。

 

ということで僕は、

  • 既存システムの運用に活かせる知識を学ぶ
  • 用提案にもっと説得力を持たせる

ためにITサービスマネージャ試験を取りに行こうと思います。

 

資格試験を取ると会社から報奨金が出るのも嬉しいです。取れたら嫁と子供になにかプレゼントしようと思います。

 

 

 

上記のテキスト&問題集をサラっと読んでみたところ、もうすこし基礎勉強が必要だなぁと思ったので、まずはITILの本を一冊読んでみるところからはじめようかと思います。

 

HULFTの必要性とは|FTPやSFTPではだめなのか?

f:id:Lync:20170413192201p:plain

出典:HULFT8 | セゾン情報システムズ

 

今回はファイル転送に用いられるHULFTについて書こうと思う。

 

HULFTの必要性。FTPやSFTPではだめなのか?

HULFTは、相手にセキュアに確実にファイルを届けるためのソフトウェアだ。

 

ファイル転送というとFTPやSFTPが頭に浮かぶと思う。LinuxOSの標準コマンドだし、カンタンなファイル転送であればFTPやSFTPで十分だ。

 

ただし、ファイル転送に関して様々な要件がついてくるとFTPやSFTP単独では対応できなくなってくる。

 たとえば、

  • 圧縮転送がしたい
  • 受信したファイルの世代管理がしたい
  • ファイル送受信のログが欲しい
  • 異なるOSやプラットフォーム間で転送がしたい
  • ファイル送受信時に文字コードの変換が必要
  • 同報配信がしたい
  • 受信エラー時に再送がしたい
  • 受信通知を受け取りたい
  • ファイルの作成や削除、更新をトリガーとしてファイルの送受信を開始したい

など、ファイル転送ひとつとっても様々な要件が考えられるし、これらをFTP等で実現するにはスクラッチ開発が必要となる。

 

スクラッチ開発をすると、スクリプトの保守がついてまわる。配信先の追加変更があるたびにスクリプトを修正していかなければならない。これは多くのシステム担当者にとって望むところではないだろう。

 ▼スクラッチ開発による弊害とHULFTのメリットについてはこのリンクが分かりやすい。

HULFT8 はじめてのHULFT | セゾン情報システムズ

 

そこでHULFTの出番だ。HULFTはこれらの機能を標準で提供しているので、カンタンな操作手順で実装ができるし、運用保守もラクだ。サポートがあるのも心強い。HULFTがもつ機能について一部紹介しよう。

  • 同期転送と非同期転送
  • 同報配信
  • ジョブ機能
  • 圧縮転送
  • 集配完了通知
  • 制御範囲や管理権限
  • 世代や履歴の管理
  • データ形式や文字コードの変換
  • 整合性検証
  • 複数ファイルの結合
  • 間欠転送
  • その他各種機能

出典:業務システムに不可欠なファイル転送機能を実現するHULFT | HULFT活用コラム | セゾン情報システムズ 

 

検証ライセンスを利用して検証をしてみよう

HULFTには検証ライセンスがある。セゾン情報システムのサイトからダウンロードが可能だ。次回からはこの検証ライセンスを利用して、実際にHULFTのインストールから設定までをしてみたいと思う。

 

参照:

つくって学ぶ、サーバ証明書(SHA1・SHA2・CSR・自己証明書)について

サーバ証明書は、Webシステムを作る上で必須の知識だが、ちゃんと理解してる人は意外と少ない。

今回は、そんなサーバ証明書について検証を通して学ぼう。

 

検証環境

AWS上のEC2インスタンス。

AmazonLinux+Apache+mod_ssl+OpenSSL

 

EC2インスタンスを作ったら、予めApacheとmod_sslとOpenSSLをインストールしておこう。

# yum install httpd mod_ssl openssl

 

サーバ証明書の作成手順

サーバ証明書を実際に作ってみよう。手順としては、次のような流れとなる。

  1. 秘密鍵の生成
  2. 公開鍵の生成。公開鍵を使ってCSR(証明書作成要求)の作成。
  3. CSRをCA(認証局)に提示して、サーバ証明書を発行してもらう。

それでは早速作ってみよう。

 

1.秘密鍵の生成

# openssl genrsa 2048 > server_sec.key

このコマンドで秘密鍵(server_sec.keyとした)を生成する。生成した秘密鍵の中身は、このコマンドで確認することができる。

# openssl rsa -text < server_sec.key

 

2.公開鍵の生成。公開鍵を使ってCSR(証明書作成要求)の作成

CSRは公開鍵と作成時に入力する項目から作成される。そのため、まずは秘密鍵から公開鍵を作成する必要がある(この秘密鍵と公開鍵のことをキーペアと呼ぶ)。

しかし実際には、下記コマンド1行で、

  • 秘密鍵から公開鍵の作成
  • 公開鍵からCSRの作成

を実施することが可能だ。

# openssl req -new -key server.key > server.csr

 

3.CSRをCA(認証局)に提示して、サーバ証明書を発行してもらう

あとは、このCSRを認証局に提示して、サーバ証明書を発行してもらえば、サーバ証明書の完成だ。

おそらく認証局のWebサイトでCSRをコピペするような手順になるだろう。

 

ところで、認証局はCSRを受領してからどのような操作を実施しているのだろうか?

その前にサーバ証明書とは何か?について学習しておく必要がある。

 

サーバ証明書とはなにか? 

サーバ証明書について書く前に、「署名」について書こうと思う。

署名とは、受領したCSRから算出したハッシュ値を、認証局の秘密鍵で暗号化したものだ。このときに使われるハッシュ関数がSHA-1、SHA-2などになる(ハッシュ値の算出には、ハッシュ関数が必要だ)。 

そしてサーバ証明書とは、CSRに認証局の署名をつけたもののことを言う。

 

グローバルサインでは、提出されたCSRに認証機関としての署名をして、サーバ証明書を発行します。

参照:[FAQ] CSRについて教えてください。 | SSL・電子証明書ならGMOグローバルサイン

 

つまり認証局は、CSRを受領してから認証局の秘密鍵を使って、CSRに署名を付与する作業を実施しているのだ。

 

自己証明書とは?

ちなみに自己証明書とは、CAによる署名(秘密鍵による暗号化)ではなく、自身の秘密鍵で署名をしたサーバ証明書のこと。

先程の環境におけるコマンドはこちら。

# openssl x509 -req -signkey server.key < server.csr > server.crt

 

自己証明書を利用してWebサーバにhttpsでアクセスしてみよう

さて、作成した自己証明書をWebサーバにセットして、クライアントからhttpsでアクセスしてみよう。

 

ApacheのConfigを編集して、SSLのアクセスを受けられるようにする。

# cd /etc/httpd/conf

# vi + httpd.conf

<最下行に下記を追加>

--------------------------

<VirtualHost _default_:443>

SSLEngine on

SSLCertificateFile /etc/httpd/server.crt

SSLCertificateKeyFile /etc/httpd/server.key

</VirtualHost>

-------------------------- 

 

編集が終わったら、Apacheを再起動する。

# service httpd restart

 

これでSSLの通信が受けられるようになっているはずだ。ブラウザからhttpsでアクセスしてみよう。すると、こんな画面が出る。

f:id:Lync:20170304005243j:plain

今回、この画面が出ている理由は「自己証明書」を利用しているからだ。

 

パブリック認証局から発行された証明書を利用して、正しいFQDNでアクセスすれば、この警告は表示されない。 

 

SHA-1、SHA-2とは?

ちなみに最近良く言われる『SHA-1』『SHA-2』とは、署名のときに利用されるハッシュ関数のこと。

 

(先に書いたが、CSRからハッシュ値を算出して、そのハッシュ値に対して、認証局の秘密鍵で暗号化するのが、『署名』だ。)

 

SHA-2にはSHA-224、SHA-256、SHA-384、SHA-512の4つのバリエーションがあり、末尾の数字がハッシュ値のビット長を表している。最長であるSHA-512が最も安全性が高いが、一般的にはSHA-256が最もよく利用されています。

 

参考サイト:

 

SHA1証明書を利用しているサイトには『完全にアクセスできなくなる』のか?

f:id:Lync:20170304010027p:plain

 

先日、下記のようなサイトを見かけた。

▶『企業サイトが表示されなくなる日、迫る「SHA-2移行問題」 | IT Leaders

 

一見すると、SHA1証明書を利用したサイトには、完全にアクセスできなくなるような印象を受ける。内容を見てもそんな感じだ。

本当にそうなのか?今回は、少し気になって調査・検証してみた。

 

SHA1証明書を利用しているサイトには『完全にアクセスできなくなる』のか?

 

結論から言うと、SHA-1サイトが2017年1月以降で完全に見えなくなるわけではないようだ。

 

参考サイト:

 

 

また、念のためSHA1の自己証明書を利用したWebサーバを作成して、ブラウザでアクセスしてみた。FireFox、GoogleChromeそれぞれ最新版でアクセスしてみたが特段アクセスできないことはなかった(2017/3/4時点の検証)。

参考までにChromeの画面ショットがこれだ。

 

▼Google Chromeでの検証結果。

Webサイトにアクセスすると警告画面は表示されるものの…

f:id:Lync:20170304005243j:plain

画面下の〜にアクセスする(安全ではありません)をクリックすると、ページが正常に表示された。

f:id:Lync:20170304005522j:plain

 

ただ、企業サイトにおいてアクセス時にセキュリティ警告画面が表示されてしまってはユーザにびっくりされてしまう。また、SHA-1の脆弱性を悪用される危険性が高まっていることに変わりはない。

そのため、サイト運営者にとっては実質的に適用は必須となるだろう。


しかし、検証サイトなどにおける自己証明書にSHA1証明書を使うこと自体に問題はなさそうだ。(本番データは置かない、一般に公開しないなどのセキュリティの対策は別途取る必要がある)

 

とはいえ、Microsoftでは、将来的にSHA1証明書を利用できなくなることも検討されているらしい。


 

いずれにしてもSHA1を本番サービスで利用しているサイト管理者は、早めの対応が必要となりそうだ。

VM Hosted Apps: VDIで仮想アプリケーション?

f:id:Lync:20160709175159p:plain

今回は、XenApp/XenDesktopで利用可能な『VM Hosted Apps』をご紹介します。

 

VM Hosted Appsとは?

まずはVM Hosted Appsがどのような機能なのかザックリと。

VM Hosted Appsは、サーバー上の仮想マシン上に仮想デスクトップ環境を構築し、そこで実行されるアプリケーションの画面をクライアントに配信する。XenAppが仮想サーバーと物理サーバーの間に入り込む形となることで、アプリケーションに対してXenAppの介在を意識させることがないため、従来XenApp環境では動作しなかった特定のアプリケーションに対しても完全な互換性を実現できるという。

出典:ASCII.jp:Citrix XenApp 6でオンデマンドデスクトップの新標準へ

 

VM Hosted Appsによってアプリケーション配信している例がCitrixBlogsにあります。Windows10のデスクトップ画面上に、VM Hosted Appsを利用してWindows 7 のメモ帳を配信している様子をご覧いただけます(下図参照)。

f:id:Lync:20160709174601p:plain

出典:VM Hosted Apps: VDIで仮想アプリケーション? | Citrix Blogs

 

▼CitrixBlogsの記事はこちらから。

www.citrix.com

 

VM Hosted Appsのメリット

ではVM Hosted Appsのメリットは何でしょうか?

それは、サーバOSで動作できないアプリケーションをサーバOSから操作することができるということです。たとえば、VM Hosted AppsによってWindows 7などのデスクトップOSで実行するアプリケーションをサーバーOSから操作することができるようになります。

 

VM Hosted Appsの注意点

VM Hosted Appsの注意点としては、配信元のカタログがデスクトップOS(クライアントOS)に限られること。デスクトップOSでは、利用するユーザーはひとつのOSあたり一人なので、利用するユーザーの数だけデリバリーグループでマシンを用意する必要があります。

 


いかがでしたでしょうか?

VMwareにはThinApp等の機能がありますが、Citrixで実現したい時にはこの機能が役に立つかもしれませんね。

Linux OSリソースのパフォーマンス分析

f:id:Lync:20160708221944p:plain

 

Linux OSリソースのパフォーマンス分析が必要な時に参照してほしい記事がこちら。

 

Linux OSリソースのパフォーマンス分析(1) ~ OSリソースを取得してみよう (1/3):CodeZine(コードジン)

 

Linux OSリソースのパフォーマンス分析(2) ~ CPUとメモリの使用状況を分析してみよう (1/3):CodeZine(コードジン)

 

Linux OSリソースのパフォーマンス分析(3) ~ ストレージとネットワークの使用状況を分析してみよう (1/4):CodeZine(コードジン)

 

「なんかパフォーマンスが出ないんだよね・・・」というとき『なんか』のままでは対策はできません。

Linuxサーバに原因があるときはコマンドを打ちながらボトルネックを探していくことになると思いますが、そのときの考え方や打つべきコマンドを説明してくれています。

 

Linux OSのパフォーマン分析時にぜひ。

はじめてのクライアント仮想化(Citrix XenApp/Desktop, VMware Horizon)

f:id:Lync:20160705203959j:plain

出典:http://it.impressbm.co.jp/articles/-/10941

 

近年、国内でもクライアント仮想化の流れが大きくなっています▼。

【VDI】2020年にはクライアント仮想化導入率は42.3%にまで成長ーIDC - 社内システムをつくろう!

セキュリティの確保、リモートワーク、モバイルワークなどのニーズが高まっていることが理由でしょう。

 

さて、クライアント仮想化を実現する代表的な製品といえば、Citrix社の『XenApp』『XenDesktop』とVMware社の『VMware Horizon』。今回はこれらの違いや製品選定のポイントをまとめていきます。

 

【ステップ1】まずはXenAppとXenDesktopの違い

デスクトップの配信はXenDesktopでアプリの配信はXenApp?

まずはXenDesktopとXenAppについてお話しましょう。

これらの2製品の機能の違いは何でしょうか?

『デスクトップの配信はXenDesktopでアプリの配信はXenAppでしょ?』製品名からなんとなくこう考えてしまう人が多いと思いますが、そうではありません

一般的に、デスクトップ仮想化を実現するなら「XenDesktop」、アプリケーション仮想化を実現するなら「XenApp」を導入する必要があると捉えられていますが、この考えは正しくはありません。

出典:Citrix XenDesktop、XenAppの導入 | アシスト

では両者の違いは、何なのでしょうか?結論から言うと答えはその配信方式です。つまり、

  • XenDesktop…VDI方式でクライアント仮想化
  • XenApp…RDS方式でクライアント仮想化

というのが両者の違いとなります。では、VDI方式とRDS方式方式とは何でしょうか?次はこれらの方式について理解しましょう。

VDI方式とRDS方式

代表的なクライアント仮想化の方式には、仮想デスクトップ(VDI)とリモートデスクトップサービス(RDS)の2つの方式があります。それぞれの方式について説明すると、

  • 仮想デスクトップ (VDI) ・・・用意された仮想マシン一つ一つが各ユーザーに割り当てられます
  • リモートデスクトップサービス (RDS) ・・・Windows Serverの OS に備わっている機能を利用して複数のユーザーが一つの OS を共有して利用します。ユーザーはデスクトップ丸ごと、またはアプリケーションのみを使用することが可能で、これらは公開デスクトップ / 公開アプリケーションと呼ばれます。

出典:新卒2年目SE社員が贈る 仮想デスクトップのキソ! 第1回 ~仮想デスクトップと Horizon 6 ( with View)~ - VMware Japan End-User Computing Blog - VMware Blogs

これらのイメージは先ほど引用したアシスト社のWebを見るとわかりやすいかと思います。

◆VDI方式

f:id:Lync:20160705202753p:plain

出典:Citrix XenDesktop、XenAppの導入 | アシスト

◆RDS方式

f:id:Lync:20160705202803p:plain

出典:Citrix XenDesktop、XenAppの導入 | アシスト

 

XenAppでもWindowsServerのデスクトップ配信は可能なんですね。ただし、XenAppではクライアントOSのデスクトップ配信は出来ません。

 

【ステップ2】VDI方式とRDS方式のメリデメを比較してみる!

次のステップではVDI方式とRDS方式のメリデメを比較し、環境ごとに最適な配信方式を選択・提案できるようになりましょう。

まずはこちらの図をご覧下さい。サーバVDIと書いてあるほうがRDS方式ですね。

 

f:id:Lync:20160707214556p:plain

出典:新卒2年目SE社員が贈る 仮想デスクトップのキソ! 第1回 ~仮想デスクトップと Horizon 6 ( with View)~ - VMware Japan End-User Computing Blog - VMware Blogs

 

それでは上図を見ながら、それぞれの方式のメリデメを理解していきましょう。

 

◆VDI方式のメリデメ

VDI方式については、クライアントOS用のアプリケーションが利用できる一方、1人1台の仮想マシン&クライアントOSを容易することになるためライセンス費用が高くなりやすいというデメリットがあります。

また、上図には記載されていませんが、仮想マシン障害時の影響範囲を小さくすることが可能です。なぜならRDS方式と違って、仮想マシンを複数人で共有していないからです。

◆RDS方式のメリデメ

RDS方式は、クライアントOSで動作しないアプリケーションの利用は基本的にはできません。ただし、複数人で一つのサーバを共有することになりますので、OSライセンス費用を圧縮することが可能となります。

ただし、仮想マシンを複数人で共有しているということは、仮想マシン障害時の影響範囲が大きくなるという点も意味します。

 

◆随時追記中!

本日はここまで。随時更新していきますので、今後ともよろしくお願いします。