重要なプロセスを、さまざまなハードウェアおよびソフトウェア・コンポーネントからなる従来の社内システムから社外のデータ・センターへと積極的にアウトソーシングするモデルに移行する企業が次第に増えてきています。これらのアウトソーシング先のデータ・センターは、内部的なコンピューティング関連のニーズだけでなく、外部的な顧客対応のニーズ (意思疎通の促進、製品のデモンストレーション、受注処理、製品のフルフィルメントなど) にも対応するように設計され、管理されます。

このマイグレーションに必要不可欠な要件は、マイグレーション後も引き続き、重要な社内情報および機密顧客データへのアクセスを、これらのデータに対してアクセスおよび管理を行う権限を付与されたユーザーだけに制限することです。

この記事では、IBM Cloud に接続するための極めて効果的かつセキュアな SSH 接続ソリューションを選択、実装、およびアップグレードする上での基礎を説明します。記事ではまず、クラウドへのマイグレーションにおける最近の傾向を探ります。続いて、社内で扱ってきた重要なプロセスをクラウド・ベースのソリューションへと切り替える際に検討しなければならない重要な領域を調べます。そして最後に、既存のエンド・ツー・エンドのクライアント・サーバー間の SSH セキュリティー・ソリューションを紹介して記事を締めくくります。

セキュアなクラウド・アクセスをする上での課題

潜在的クラウド・ユーザーが抱く懸念の 1 つは、データをセキュアな社内の場所から、社内ほど安全ではないかもしれない外部の場所に移す際に、データが漏えいするのではないかという懸念です。クラウド・インスタンス自体は、Windows Active Directory や NTFS ファイルシステム、そしてファイアウォールを使用することでセキュアにすることができますが、データの転送は問題になる可能性があります。

以下の問題に対処しなければ、実際に多大な損害をもたらすセキュリティー侵害を招く恐れがあります。

• 平文での送信: ユーザー名とパスワードを始めとし、すべての通信が平文で行われる。
• 認証強度が弱いクライアント認証: 一般的に採用されているセキュアでないアクセス方法は、幾度となく信頼できないことが明らかになっている、ユーザー名とパスワードのみによるユーザー認証手法を用いるもので、公開/秘密鍵、Kerberos、デジタル証明書などの高度な認証手法をまったくサポートしていません。
• サーバー認証の欠如: サーバー認証が行われなければ、ユーザーは、通信している相手が意図するサーバーであること、そしてサーバーになりすました攻撃者ではないことを確認することができません。
• データ完全性の欠如: データ完全性を確保しなければ、誰でも検知されることなく、サーバーとクライアントの間で送受信されるデータを改ざんしたり、破損させたりすることができます。

上記の問題では、クラウド・データへのモバイル・アクセスが急増していることも考慮に入れなければなりません。最近では、従業員が以下の行動を取ることは珍しくありません。

• 倉庫でスマート・フォンやタブレットを使用して在庫を調べる
• 現場にいる間に情報を収集する
• 複数のチェックポイントで製品を追跡する
• 車内や空港のラウンジから本社にデータを送信する

ある概算では、2014年にはモバイル・インターネットの使用量がデスクトップでのインターネットの使用量を上回ると予測しています。現に、社内ネットワークに対するすべての検索のうち、50 パーセントを超える検索がモバイル機器から行われるようになっています。

ハッカーたちの技術的手腕が磨かれてきていることは言うまでもなく、米国政府によるプライバシーおよびデータ保護に関する法規制が大量にあることを考えると、企業環境において従業員がモバイル機器からネットワークへリモート・アクセスするのを許可することは受け入れられなくなってきています。

変化を好まないユーザーや企業がこれまで内部で行っていたプロセスをクラウドへ切り替えることに消極的なのは誰もが承知しています。それでも企業とその従業員が、クラウドへの切り替えによって業務で使用するデータが置かれる地理的地域を設定し直す際には、多数のアクセス・ポイントをマイグレーションしてクラウドに保管されるデータにアクセスできるようにする作業を、最大限セキュアに行えるように注力することに最も重点が置かれるはずです。

米国におけるプライバシーに関する法規制について、私たちのほとんどが、この 10 年の間に利用者および企業のプライバシーを保護するための連邦規制が設けられたことも認識しています。例えば、以下に挙げるような規制が設けられました。

• PCI-DSS (Payment Card, Industry Data Security Standard: クレジット・カード業界データ・セキュリティー基準)(2004年、2009年 1月更新): PCI-DSS は、クレジット・カード情報を処理、保存、伝送する方法を規制しています。ワイヤレス・ネットワークでこの標準の要件に対応するには、暗号化の欠如、強度の弱い認証、データ完全性の欠如がすべて当てはまる Telnet ではまったく不適切です。
  
  
• GLBA (Gramm-Leach-Bliley Act: グラム・リーチ・ブライリー法)(1999年): GLBA は、金融業界が顧客の情報を適切に保護することを要求しています。この要件についても、Telnet や FTP で対処するのは非現実的です。
  
  
• Sarbox (Sarbanes-Oxley:サーベンス・オクスリー法)(2002年): Sarbox は、あらゆる株式公開企業の経済的実態が財務報告書に正確に反映されることを保証する、厳格な内部統制の実施を要求しています。IT システムの審査を担当する監査人のほとんどは、Telnet や FTP によるリモート・コンピューティング・アクティビティーをなくすように求めるはずです。
  
  
• HIPAA (Health Insurance Portability and Accountability Act: 医療保険の相互運用性と説明責任に関する法律)(1996年): この医療業界の規制では、何よりもまず、医師が患者の情報を暗号化して保護することを要求しています。この要件についても同じく、Telnet や FTP で対処するのは不可能です。
  
  
• FIPS (Federal Information Processing Standards: 連邦情報処理規格) へのコンプライアンス: 商務長官は Information Technology Management Reform Act (情報技術マネジメント改革法)(Public Law 104-106) の下、NIST (National Institute of Standards and Technology: 米国国立標準技術研究所) が連邦コンピューター・システムを対象に開発した規格およびガイドラインを承認しています。NIST はこれらの規格およびガイドラインを、政府全体に適用される FIPS として発行しています。NIST は、米国連邦政府によって規定された要件がある一方、セキュリティーや相互運用性などに関して、条件を満たす業界ソリューションや規格がない場合に FIPS を作成します。

  このプログラムの一部となっている CMVP (Cryptographic Module Validation Program: 暗号モジュール認証制度) は、暗号モジュールが FIPS に準拠しているかどうかを検証する認証制度です。CMVP は NIST とカナダ政府の CSE (Communications Security Establishment: 通信安全保障局) が共同で取り組んでいます。この制度によって検証された暗号モジュールは、独立認定機関である CMT (Cryptographic Module Testing: 暗号モジュールテスト) 研究所の厳格なテストを受けることになります。

単なる法規制を発布するだけでなく、米国連邦政府は最近になって、政府のデータ・センターの 6 ヶ月間にわたる調査を開始しました。調査結果は、広がりつつあるパブリック・データ・センターの統合作業の下地となる予定です。この政府発表を受けて、ニューヨーク市でも同様のイニシアチブを開始しました。

政府機関がデータ・センターおよびストレージ機能の無駄を省き、より多くの機能をクラウド内に移すそうと取り組んでいるなか、業界専門家たちの多くは、これらの大規模なイニシアチブにより、リモート・コンピューティングのセキュリティー確保を目的としたデータおよびプライバシー保護に関する法規制がさらに導入されるだろうと予測しています。

上に戻る

セキュアなクラウド・アクセス手法としての SSH

このセクションで説明する SSH のコンポーネントにより、SSH はセキュアなクラウド・アクセス手法の最有力候補となります。

SSH は、ネットワークで接続された任意の機器の間で、セキュア・チャネルを使用したデータ交換を可能にするネットワーク・プロトコルです。SSH は、Telnet、FTP、そしてその他のセキュアでないリモート・シェルの代替手段になるものとして 1995年にゼロから設計されました。

SSH では暗号化を使用して、セキュアでないネットワークで伝送されるデータの機密性および完全性を確保します。適切な SSH ソリューションを使用することで、企業は以下に挙げる不正行為に対する保護対策を採ることができます。

• ネットワーク上を伝送されるデータの傍受
• ネットワーク内の中間要素 (ルーターなど) でのデータの不正操作
• IP アドレスのスプーフィング
• 信頼できるホスト名/IP アドレスの DNS スプーフィング
• IP ソースのルーティング

時とともに SSH の役割は広がり、今ではセキュアなリモート・アクセス、セキュアなファイル転送、そしてセキュアなトンネリング接続の事実上の業界標準となっています。しかし、おそらくそれよりももっと重要な点として、SSH はアプリケーションをサーバーからデスクトップ・クライアントやモバイル・クライアントに配布するのに最も適したセキュアな送信手段となったことです。

SSH は RFC 標準として制定されています。セキュアなリモート・データ通信を支援する上で SSH が果たす役割について、以下の RFC に詳しく説明されています。

• RFC 4250: SSH Protocol Assigned Numbers (SSH プロトコルの割り当て番号)
• RFC 4251: The Secure Shell (SSH) Protocol Architecture (セキュア・シェル (SSH) プロトコル・アーキテクチャー)
• RFC 4252: The Secure Shell (SSH) Authentication Protocol (セキュア・シェル (SSH) 認証プロトコル)
• RFC 4253: The Secure Shell (SSH) Transport Layer Protocol (セキュア・シェル (SSH) トランスポート層プロトコル)
• RFC 4254: The Secure Shell (SSH) Connection Protocol (セキュア・シェル (SSH) 接続プロトコル)
• RFC 4256: Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) (セキュア・シェル・プロトコル (SSH) の汎用メッセージ交換認証)
• RFC 4335: The Secure Shell (SSH) Session Channel Break Extension (セキュア・シェル (SSH) セッション・チャネルの中断による拡張)
• RFC 4344: The Secure Shell (SSH) Transport Layer Encryption Modes (セキュア・シェル (SSH) トランスポート層暗号化方式)

Cisco ルーターから企業の本番サーバーに至るまで、Microsoft Windows、UNIX、Apple Mac、Linux などのさまざまなプラットフォームで SSH を使用して以下のようなタスクを行うことができます。

• リモート・ホスト上のシェルにログインする (Telnet および rlogin の代替手段として使用)。

  標準的な SSH クライアントを使用してシェルにアクセスする。

• リモート・ホスト上で単一のコマンドを実行する (rsh の代替手段として使用)。

  以下のように SSH 接続にコマンドを渡すと、そのコマンドが自動的に実行されます。

  ssh user@server c:\temp\batch_file_to_launch

  
  
• SFTP (Secure FTP) や SCP (Secure Copy Protocol) を使用して、ローカル・サーバーからリモート・ホストにファイルをコピーする。以下のようにファイル・コピーのオプションを指定します。

  scp source_file user@sshServer:drive:\dest_directory\dest_file

  
  
• SFTP (FTP に代わるセキュアな方法) を併用して、ファイルを転送する。SFTP はセキュアな FTP であり、FTP クライアントを使用して接続できると誤解されていることがよくありますが、SFTP サーバーに接続するには SFTP クライアントが必要です。
• rsync によるバックアップを組み合わせて、効率的かつセキュアにファイルをコピーおよびミラーリングする。
• スクリプトを使用してファイルを自動的にコピーする。以下のコードは、Pragma Systems の SFTP クライアント・コマンドを使用したスクリプトの例です。

  sftp user@sftp_server -b batchfile -L logfile

  
  

  以下のバッチ・ファイルに、ファイル転送を含めることができます。

  cd userlogs mput *.log cd \serverlogs mget *.logs

  
  
• ポートを転送またはトンネリングする。ポート・フォワーディングでよくある間違いは、ローカル・ポートではなく、リモート・ホストに接続することです。ポート・フォワーディングを使用する場合、ssh 接続によってローカル接続をトンネリングし、セッション全体を暗号化することができます。また、自動でポート・フォワーディングを行うのに便利な方法として、バッチ・ファイルでポート・フォワーディングをセットアップし、そのバッチ・ファイルをユーザーのログオン・スクリプトとして実行することもできます。
  • ポート・フォワーディングを使用して、Web トラフィックをトンネリングすることができます。それにはまず、ポート・フォワーディングによって、SSH クライアントを開き、接続します。
    

    ssh user@ssh_server -L 8080:internal_webserver:80

    
    
    次にローカルで接続し、ポート http://localhost:8080 を介してトラフィックをトンネリングします。
  • e-メール・トラフィックを使用することができます。SSH クライアントを開き、ポート・フォワーディングによって接続します。
    

    ssh user@ssh_server -L

    
    
• リモート・ホストから転送する (複数の中間ホストを使用することが可能です)。
• SOCKS プロトコルをサポートする SSH クライアントとの暗号化プロキシー接続によって、Web をブラウズする。
• SSHFS を使用して、リモート・サーバー上にローカル・コンピューター上のファイルシステムとしてディレクトリーをマウントする。
• 上記のメカニズムを 1 つ以上使用して、リモートからのサーバーの監視や管理を自動化する。
• 複数の SSH シェル・チャネル・ユーザーとセキュアに連携する。この場合、セッションの転送、交換、共有、さらには切断されたセッションのリカバリーが可能になります。

以上のタスクやニーズに対処する上で、SSH はクラウドにいつでも、どこからでもセキュアにアクセスする適切な方法のように思えますが、検討しなければならないことはまだあります。それは、SSH 単独で、すべてのニーズ、そして現場から行う必要があるすべての作業に対応できるかどうかです。

以下の場合には、SSH 単独で対応することができます。

• コマンドライン・アクセスだけが必要である。
• 単一のコマンドをスクリプトまたはインタラクティブな方法で実行したい。
• コマンドラインですべての管理作業を実行できる。
• 単一のポートを介してすべてのトラフィックをセキュアにしたい。
• ファイアウォールで単一のポートを開きたい。
• サーバーに素早くアクセスしたい。

以下の場合には、VPN またはターミナル・サービスによるアクセスが必要になります。

• グラフィカル・プログラムを実行する必要がある。
• ユーザー・コンテキストで複数のプログラムにフル・アクセスしたい。

以上のことから、クラウドに SSH を実装する場合のベスト・プラクティスとして、次のことを覚えておいてください。

• GUI 接続は、プロセッサーに大きな負荷がかかります。サーバーによっては、GUI 接続を禁止するかもしれません。コマンドライン・アクセスの場合には、少ない負荷で素早く接続することができます。
  
  
• リモートからサーバーを管理してコンソール・アプリケーションを実行するには、SSH は理想的です。GUI によって行われるほとんどすべての管理作業は、コマンドラインから実行することができます。Windows では、コマンドラインで管理できるように PowerShell やその他のコマンドライン・ツールを提供しています。
  
  
• SSH は RFC 標準であることから、特定のプラットフォームに依存しない接続が可能になります。Linux や Windows、さらには RF gun (訳注: Motorola 製のモバイル・コンピューター MC9000 シリーズのこと。銃に形が似ていて無線 LAN 機能を搭載していることから、このように呼ばれることがある。) や携帯電話などといった携帯型の機器でも、SSH で接続してファイルを転送したり、アプリケーションを実行したりすることが可能です。
  
  
• クラウドの Windows インスタンスで SSH を使用すると、Linux クラウド・インスタンスが現在提供している基本的な機能の一部を Windows でも使用できるようになります。しかもこれらの機能は、一般的な Windows ベースのシステムで使用しているように、柔軟で使いやすいものになっています。

次のセクションでは、クラウドに SSH でアクセスするための要件を満たすことができる既存のシステムについて簡単に説明し、このシステムが PCI 規制などの実際の要件に対処する仕組みについて見ていきます。

上に戻る

実際の SSH ソリューション

Pragma Systems の Fortress SSH Server は、簡単にインストールできて、直観的に使用できる SSH サーバーです。このソフトウェアを構成するには、ダイアログ･ウィンドウまたはコマンドライン・プログラムを使用することができます。また、カスタマイズするのも簡単で、ユーザー定義のログイン・スクリプトやカスタマイズ可能なログイン・シェルを使用できるようになっています。Fortress SSH Server はまた、大規模な企業環境にシームレスに、しかも簡単にデプロイできるように設計されています。

これから、Fortress SSH を使用して PCI (Payment Card Industry: クレジット・カード業界) のセキュリティー要件を満たす実装事例について説明します。

重要な支払情報を転送するためのセキュアなデータ転送要件として、PCI が主要項目を記しているなかで、重要な項目の 1 つが、要件セクション 4.1 の 4.1.1 の「オープンな公衆ネットワーク上でカード会員情報を送信する場合、暗号化すること」です。つまり、送信中のデータをハッカーが簡単に傍受、改ざん、迂回できてしまうようなネットワークで機密性の高い情報を送信する際には、その情報を暗号化しなければなりません。以下に、これらの要件の内容を具体的に説明します。

• 4.1: 機密性の高いカード会員情報をオープンな公衆ネットワークで送信する場合、送信中のデータを保護するために、SSL (Secure Sockets Layer)/TLS (Transport Layer Security) および IPSEC (Internet Protocol SECurity) などの強力な暗号化およびセキュリティー・プロトコルを使用すること。
  
  
• 4.1.1: ワイヤレス・ネットワークでカード会員情報を送信する場合、WPA (WiFi Protected Access) または WPA2 技術、IPSEC VPN、あるいは SSL/TLS で送信データを暗号化すること。無線 LAN を利用しながら機密情報を保護するには、決して WEP (Wired Equivalent Privacy) のみに頼らないこと。
  
  WEP を使用する場合には、以下の要件が適用されます。
  • 少なくとも 104 ビットの暗号鍵および 24 ビットの初期値を使用すること。
  • 必ず WPA または WPA2 技術、VPN、あるいは SSL/TLS と組み合わせて使用すること。
  • 共有 WEP 鍵を 3 ヶ月ごとに (技術によっては自動的に) 変えること。
  • 鍵にアクセスできる人が変わった場合には必ず共有 WEP 鍵を変えること。
  • MAC (Media Access Code) アドレスに基づいてアクセスを制限すること。

セクション 4.1 および 4.1.1 を読む上で注意しなければならない重要なことは、SSH (Pragma の Fortress SSH を含む) は SSL/TLS および IPSEC と同じ暗号化メカニズムを使用するだけでなく、さらに一歩進めてセキュリティー機能を追加していることです。

SSL は、TLS の古いバージョンです。TLS 1.0 は SSL 3.0 に相当します。SSL/TLS が Web による e-コマースをセキュアにするために設計され、IPSEC が VPN アクセスを提供するために設計されたのと同じく、SSH はセキュアなリモート・アクセスと (SFTP による) セキュアなファイル転送を実現するために考案されました。RFC 標準となった SSH と SFTP は、業界で広範にデプロイおよび採用されています。

さらに、インターネットを対象とした RFC Overview Notes では、TLS レコード・プロトコルの 2 つの基本特性を挙げています。

1. 接続が公開されないこと。データ暗号化には、対称暗号化 (DES [DES] や RC4 [RC4] など) が使用されます。この対称暗号化に使用される鍵は、接続ごとに一意に生成されるもので、そのベースとなるのは、TLS ハンドシェーク・プロトコルなどの別のプロトコルによってネゴシエーションされたシークレットです。このレコード・プロトコルは、暗号化なしで使用することもできます。
   
   
2. 接続が信頼できること。メッセージの送受信が行われる際には、鍵付き MAC を使用したメッセージの完全性チェックが行われます。MAC の計算には、セキュアなハッシュ関数 (SHA や MD5 など) が使用されます。このレコード・プロトコルは MAC なしでも処理を行うことができますが、通常はこの完全性チェック・モードのみが使用されます。他のプロトコルはこのレコード・プロトコルを、セキュリティー・パラメーターをネゴシエートするための通信手段として使用しています。

要するに、TLS は送信中のデータを人々が見られないようにするためのメカニズム (接続が公開されないため) であり、受信したデータが送信されたデータと同じであることを検証するためのメカニズム (接続が信頼できるため) でもあります。後者の特性は、基本的なエラー・チェック機能のように思えるかもしれませんが、実際には、ハッカーが送受信中のデータを変更できないようにすることを目的としています。

その上、RFC 4301-4309 には IPSEC が定義されています。セクション 2.1: Goals/Objectives/Requirements/Problem Description には、以下のように記述されています。

IPSEC は、相互運用可能で高品質な暗号化ベースのセキュリティーを IPv4 および IPv6 に提供することを目的に設計されています。IPSEC が提供するセキュリティー・サービスには、アクセス制御、コネクションレスな完全性、データ送信元認証、リプレイの検出と拒否 (部分的なシーケンスの完全性の形)、機密性 (暗号化を使用)、および限定されたトラフィック・フローによる機密性などがあります。これらのサービスは IP 層で提供されるため、IP 層上で使用できるすべてのプロトコル (IP 自体を含む) にとって標準的な保護手段となります。実際、IPSEC は SSL/ TLS 機能の上位集合となります。

以上のことから、暗号化とメッセージの完全性が PCI-DSS への準拠を実現する上で最も重要であることは明らかです。

Pragma Systems の Fortress SSH セキュリティー機能は IPSEC と非常によく似ており、暗号化に使用するアルゴリズムも同じ MAC (Message Authentication Code) 処理と鍵交換です。一方、SSH は暗号化機能を提供するだけにとどまらず、企業に対してセキュリティーと使いやすさとのバランスが完全にとれた手段を提供します。Fortress SSH は、認証という点では SSL/TLS や IPSEC を上回る柔軟性を提供し、セキュリティーの面では SSL/TLS や IPSEC に匹敵します。Pragma Systems の Fortress SSH 技術は、PCI DDS の要件セクション 10.2.4-10.2.5 の「ネットワーク・リソースおよびカード会員データに対するすべてのアクセスを追跡および監視すること」で記述されている Telnet の問題に直接対処し、パスワード、公開鍵、および Kerberos 認証メカニズムを採り入れた堅牢な認証機能を提供します。また、無効なログイン試行および有効な接続を容易に追跡、記録できるようにもなっています。

ロギング・メカニズム、そしてユーザー・アクティビティーの追跡機能は極めて重要です。あらゆる環境でログを使用できれば、問題が起こった場合に徹底的な追跡および分析を行うことができます。システム・アクティビティーのログなしでセキュリティー侵害の原因を判別するのは至難の業です。

上に戻る

まとめ

この記事では、セキュアなクラウド・アクセスを実現する際の課題と、SSH を使用してセキュアなクラウド・アクセス・システムを実装する方法 (そして、そのために必要なコンポーネント) を説明しました。さらに、クラウド環境での効果的な SSH アクセス・システムを実装するためのベスト・プラクティスを概説した後、Pragma System の Fortress SSH 製品での実例を紹介しました。

参考文献

学ぶために

• developerWorks には、この記事との関連で興味深い SSH の使用法に関する広範なリソースが揃っています。
  • 「Tunneling with SSH」は、Windows と UNIX とのセキュアな接続を具体的に説明している優れた記事です。
  • 「Three locks for your SSH door」では、SSH を使用できるユーザーを指定する方法、ポート・ノッキング手法、およびSSH アクセスの存在を隠す方法について説明しています。
  • 「More locks for your SSH door」では、上記の記事の続編として、パスワードを排除し、代わりに公開/秘密鍵のペアを使用して SSH アクセスを強化する方法、さらに、安全でないと識別された送信元へのサーバー・アクセスを拒否することによって、総当たり攻撃や辞書攻撃などの考えられる攻撃を認識し、阻止する方法を説明しています。
  • 「VNC と SSH による、IBM Cloud インスタンスへのセキュアなマルチユーザー・アクセス」では、セキュアなリモート・グラフィカル・アクセスを実現するためにクラウド・インスタンスおよびクライアントを構成する方法を説明しています。
  • 「Android 機器からセキュアにアクセスする」では、IBM Cloud インスタンスにセキュアにアクセスする Android モバイル機器をセットアップする方法を説明しています。
  
  
• IBM Cloud でさまざまなタスクを実行する方法を学ぶために、以下のリソースをご覧ください。
  • ナレッジ・パス:「Cloud computing: Build an effective cloud policy」
  • 「IBM Cloud リリース 1.2 を使うためのヒント: Windows インスタンスとの間でのファイルのアップロードとダウンロード」
  • 「IBM Cloud リリース 1.2 を使うためのヒント: Windows Server 2008 R2 に IIS Web サーバーをインストールする」
  • 「Linux のコマンド・ラインを使用して IBM Cloud にインスタンスを作成する」
  • 「Windows のコマンド・ラインを使用して IBM Cloud にインスタンスを作成する」
  • 「IBM Cloud を利用して企業のネットワークを拡張する」
  • 「IBM Cloud での高可用性アプリケーション」
  • 「カスタム・インスタンスのクラウド・イメージをオンザフライでパラメーター化する」
  • 「Windows-targeted approaches to IBM Cloud provisioning」
  • 「IBM SmartCloud Enterprise についてのヒント: Rapid Deployment Service を使用して製品をデプロイする」
  • 「IBM SmartCloud Enterprise tip: Integrate your authentication policy using a proxy」
  • 「IBM SmartCloud Enterprise についてのヒント: Linux Logical Volume Manager を構成する」
  • 「IBM SmartCloud Enterprise についてのヒント: 複雑なトポロジーをデプロイする: IBM Cloud でデプロイメント・ユーティリティー･ツールを使用する」
  • 「IBM SmartCloud Enterprise についてのヒント: 別々の VLAN にまたがる: パブリック VLAN とプライベート VLAN にまたがるインスタンスをプロビジョニングし、構成する」
  • 「IBM SmartCloud Enterprise についてのヒント: Android 機器からセキュアにアクセスする」
  
  
• developerWorks のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
  
  
• IBM SmartCloud Enterprise で使用できる製品イメージのリストを調べてください。
  
  
• IBM SmartCloud Enterprise にアクセスする方法を調べてください。
  
  

製品や技術を入手するために

• IBM Cloud サイトにアクセスして、現在のクラウド・オファリングを調べてください。
  
  

議論するために

• developerWorks のクラウド・コンピューティング・グループの一員になってください。
  
  
• developerWorks でクラウドに関する優れたブログのすべてを読んでください。
  
  
• 専門家のネットワークであるとともに、互いにつながりを持ち、共有、協力するためのコミュニティー・ツールが集められている developerWorks コミュニティーに加わってください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• セキュアなクラウド・アクセスをする上での課題
• セキュアなクラウド・アクセス手法としての SSH
• 実際の SSH ソリューション
• まとめ
• 参考文献
• 著者について
• コメント