Java 開発 2.0: クラウド・コンピューティング用の Java アプリケーション・データをセキュアにする

秘密鍵を使用した暗号化によってクラウド・データを保護する

クラウドの導入を検討している組織にとって、データ・セキュリティーは深刻な懸念事項ですが、多くの場合、クラウド・データのセキュリティーを心配する必要はありません。連載「Java 開発 2.0」の今回の記事では、秘密鍵による暗号化と AES (Advanced Encryption Standard) を使用して、機密性の高いアプリケーション・データをクラウドでセキュアに保つ方法を説明します。またこの記事は、分散クラウド・データ・ストアに対して実行される条件付き検索を最大限に効率化する上で重要な暗号化戦略についての簡単なチュートリアルにもなっています。

Andrew Glover, CTO, App47

Andrew GloverAndrew Glover は、ビヘイビア駆動開発、継続的インテグレーション、アジャイル・ソフトウェア開発に情熱を持つ開発者であるとともに、著者、講演者、起業家でもあります。また、easyb BDD (Behavior-Driven Development) フレームワークの創始者、そして『継続的インテグレーション入門 開発プロセスを自動化する47の作法』、『Groovy in Action』、『Java Testing Patterns』の 3 冊の本の共著者でもあります。詳細は彼のブログにアクセスするか、Twitter で彼をフォローしてください。



2012年 2月 23日

この連載について

Java 技術が初めて登場してから現在に至るまでに、Java 開発の様相は劇的に変化しました。成熟したオープンソースのフレームワーク、そしてサービスとして提供される信頼性の高いデプロイメント・インフラストラクチャーを利用できる (借りられる) おかげで、今では Java アプリケーションを短時間かつ低コストでアセンブルし、テスト、実行、保守することが可能になっています。この連載では Andrew Glover が、この新たな Java 開発パラダイムを可能にする多種多様な技術とツールを詳しく探ります。

わずか 2、3 年の間に、クラウド・コンピューティング・プラットフォームおよびサービスは Java アプリケーション開発の様相を劇的に変えました。クラウド・コンピューティングは、システムの保守や構成に伴う障壁を引き下げ、コストを削減すると同時にソフトウェアを市場に出すまでの時間も短縮しています。企業の経営者は投資収益率を重要視し、開発者はインフラストラクチャーのコードから解放されることを切に願っていることを考えれば、クラウド・コンピューティングを導入することは、概念としては極めて妥当なことです。しかし、それでも未だに数多くの事業所がクラウド・プラットフォームに移行すべきかどうか迷っています。

ソフトウェアをクラウド・インフラストラクチャーにマイグレーションすることを検討している組織にとって重大な懸念事項の 1 つとなっているのは、データ・セキュリティーです。データの機密性が高ければ高いほど、それだけデータ・セキュリティーが懸念されます。ソフトウェア開発者としての私たちは、クラウド・コンピューティングに伴う真のセキュリティー・リスクと、こうした懸念の少なくとも一部を解決できる実際的な取り組みの両方を理解することが重要です。

連載「Java 開発 2.0」の今回の記事では、まず、クラウドにデータを保管する場合と、集中型のマシンにデータを保管する場合との違いを説明します。次に、標準の Java プラットフォームや Java プラットフォームのユーティリティーに組み込まれている、秘密鍵による暗号化の機能を使用して、データが分散クラウド・データ・ストアに保管されるとしても、それなりにデータをセキュアに保つ方法を紹介します。そして最後に、クエリーの条件を基準としてデータを暗号化するかどうかを決定する戦略的暗号化手法を具体的な例で説明します。

クラウド・データをセキュアに保つ

クラウド・コンピューティングは、必ずしもデータ・セキュリティーに関する新たな懸念をもたらすわけではありません。ほとんどの場合、懸念を増幅するだけです。クラウドにデータを置くと、より多くの人々にデータが公開される可能性があります。通常、これは良いことですが、実は非公開にしておくべきデータや、条件付きでしかアクセスできないように意図されているデータが公開された場合には、大惨事になりかねません。クラウド・コンピューティングの根本的な問題は、クラウドに委託したデータを開発者やシステム管理者が直接制御できないことにあります。データをローカルに保管して管理する場合とは異なり、クラウド内ではデータが分散された機器に保管されます。任意の場所に置かれたこれらの機器は、ことによると、誰もがアクセスできる機器かもしれません。

EU におけるデータ・プライバシー

欧州連合 (EU) におけるクラウド・プラットフォームでのデータ・プライバシーに対するアプローチは、米国よりも遥かに厳格です。EU 市民に属する個人データ (例えば、フランス市民の医療記録など) の保管場所は、EU 内のサーバーに限られています。

分散された遥か彼方のデータ・ストアにデータが保管されるという事実を企業が受け入れられるとしても、開発者としては、開発したアプリケーションに、クラウドでもささやかなデータ・セキュリティーが適用されることを願うはずです。データ・セキュリティーについて考え始めると浮上してくる重要な疑問には、次の 2 つがあります。

  • 転送中のデータはセキュアなのか?
  • 保管されているデータはセキュアなのか?

転送中のデータには、あるロケーションから別のロケーションにどのようにしてデータが渡されるのか、つまり使用している通信技術とインフラストラクチャーが関係してきます。保管されているデータには、データがどのように (そして、どれほど適切に) 保管されているかが関係してきます。例えば、ユーザー名とパスワードを暗号化せずにデータベースに保管するとしたら、保管されているデータはセキュアとは言えません。

Web で転送されるデータをセキュアに保つには、HTTPS が使用されるのが一般的です。HTTPS は、ブラウザーからサーバーに転送されるデータが暗号化された形式の HTTP です。HTTPS には普遍性という利点もあり、ほとんどの開発者は HTTPS を使用するように Apache、Tomcat、あるいは Jetty を構成しています。

暗号化は、保管されているデータをセキュアに保つための一般的なメカニズムでもあります。クラウド・コンピューティングでも、このことに変わりはありません。暗号化は難解なメカニズムかもしれませんが、ある程度の基本知識があれば、アプリケーション・データをそれなりにセキュアにすることができます。データがセキュアになれば、そのデータをローカルで提供するか、クラウド・プラットフォームやデータ・ストアを介して提供するかは大した問題ではなくなります。


秘密鍵による暗号化

暗号化とは、人間が簡単に読んで理解できるテキストを、理解不可能なテキストに変換するプロセスです。この変換プロセスは、暗号化アルゴリズム (暗号化アルゴリズムは一般に「暗号」としても知られています) を使用して行います。暗号化されたテキストを理解可能なテキストに復号するには、鍵 (基本的にはパスワード) を使用します。暗号化は、鍵がなければ情報を理解できないようにすることによって情報をセキュアにする仕組みです。

コンピューティングで使用される鍵ベースの暗号化には、公開鍵による暗号化と秘密鍵による暗号化の 2 つがあります。公開鍵による暗号化は、転送中のデータをセキュアにする最も一般的な手法であり、実際に HTTPS トランザクション・セキュリティーの基本となるアーキテクチャーでもあります。公開鍵による暗号化では、2 つの鍵を公開鍵と秘密鍵の対として使用します。公開鍵は、対となっている秘密鍵を使って暗号化されたデータしか復号することができません。公開鍵による暗号化では、公開鍵は安全に配布することができますが、秘密鍵については管理者の管理下に置かれていなければなりません。公開鍵による暗号化の場合、暗号化された情報を容易に共有することができます。

秘密鍵とプライバシー

どの暗号化アルゴリズムを使用するかに関わらず、秘密鍵は必ずセキュアに保つ必要があります。パス・フレーズは高度なセキュリティー標準を満たす必要があり、クラウド内ではなおさらのこと、平文で保管するのは厳禁です。幸い、Java プラットフォームのセキュリティー・インフラストラクチャーはかなり複雑な鍵を作成するため、Java プラットフォームの鍵ストアに保管すれば、鍵をセキュアに保つことができます。

秘密鍵による暗号化では、データの暗号化と復号の両方に同じ 1 つの秘密鍵を使用します。この暗号化方式では送信者と受信者が同じ鍵を使用する必要があるため、暗号化されたデータをサード・パーティーと共有するのは困難です。鍵のセキュリティーが侵害された場合、その鍵で暗号化されたすべての情報のセキュリティーも侵害されてしまうことになります。暗号化するデータを他の関係者と共有する必要がなく、鍵を常に厳しい管理の下に維持できる場合には、秘密鍵による暗号化が極めて有効です。

秘密鍵による暗号化は、クラウド・インフラストラクチャーによって保管および転送されるアプリケーション・データをセキュアに保つ上で有効な手段です。暗号鍵は管理者またはアプリケーション作成者の管理下に置かれるため、クラウド・プロバイダーも、あるいはデータ傍受を狙う人々も、暗号化されたデータに無制限にアクセスすることはできません。


Java アプリケーションの暗号化

Java アプリケーションをセキュアに保つ手段には、標準の Java プラットフォーム・ライブラリーをはじめ、さまざまな選択肢があります。また、暗号化標準やパッケージにも幅広い選択肢があります。そのうち、以降に記載する例で使用するのはコア Java ライブラリーと AES (Advanced Encryption Standard) です。平文を暗号化するにも、暗号文 (暗号化された平文) を復号するにも同じ秘密鍵を使用します。私が AES を気に入っている理由は、これが米国国家安全保障局 (National Security Agency) によって承認され、米国政府によって標準化されたものであるためです。

最大限の柔軟性、そしてテストを容易にすることを目的に、これから暗号インターフェースを作成し、関連するクラスを実装します。これらの実装クラスは単に、コア Java クラスをラップするためのものです。その後、Amazon の SimpleDB、さらには MongoHQ の MongoDB などのクラウド・データ・ストアに、実装クラスを使用してデータをセキュアな形で永続化する方法、さらにそのデータにクエリーを実行する方法まで紹介します。

リスト 1 に、データを暗号化するためのメソッドと、復号するためのメソッドを定義した単純な汎用暗号インターフェースを示します。このインターフェースは、さまざまなアルゴリズムで使用されます。つまり、私が実装するクラスは、AES などの特定の暗号方式を使用することになります。

リスト 1. 暗号インターフェース
package com.b50.crypto;

public interface Cryptographical {
 String encrypt(String plaintext);
 String decrypt(String ciphertext);
}

この Cryptographical インターフェースを使用すれば、テキストを暗号化することも、暗号テキストを復号することもできます。今度は Java Security API を使用して、鍵を表現するもう 1 つのインターフェースを作成します (リスト 2 を参照)。

リスト 2. 鍵インターフェース
package com.b50.crypto;

import java.security.Key;

public interface CryptoKeyable {
  Key getKey();
}

ご覧のように、上記の CryptoKeyable インターフェースの役割は、Java プラットフォームのコア Key タイプのラッパーでしかありません。

AES による暗号化を使用する場合、平文の暗号化によって生成されるバイナリー文字は、base-64 方式でエンコードする必要があります。少なくとも、(例えば SimpleDB ドメインで) これらのバイナリー文字を Web リクエストで使用するとしたら、この条件が当てはまります。したがって、暗号化されたすべての文字列をエンコードし、復号されたすべての文字列をデコードすることにします。

AES に対応する Cryptographical 実装クラス (リスト 3 を参照) は、AES 暗号化を処理するだけでなく、base-64 方式のエンコードとデコードも処理します。

リスト 3. Cryptographical インターフェースの AES 実装
package com.b50.crypto;

import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
import java.security.InvalidKeyException;
import java.security.Key;
import java.security.NoSuchAlgorithmException;

public class AESCryptoImpl implements Cryptographical {

 private Key key;
 private Cipher ecipher;
 private Cipher dcipher;

 private AESCryptoImpl(Key key) throws NoSuchAlgorithmException,
   NoSuchPaddingException, InvalidKeyException {
  this.key = key;
  this.ecipher = Cipher.getInstance("AES");
  this.dcipher = Cipher.getInstance("AES");
  this.ecipher.init(Cipher.ENCRYPT_MODE, key);
  this.dcipher.init(Cipher.DECRYPT_MODE, key);
 }

 public static Cryptographical initialize(CryptoKeyable key) throws CryptoException {
  try {
   return new AESCryptoImpl(key.getKey());
  } catch (NoSuchAlgorithmException e) {
   throw new CryptoException(e);
  } catch (NoSuchPaddingException e) {
   throw new CryptoException(e);
  } catch (InvalidKeyException e) {
   throw new CryptoException(e);
  }
 }

 public String encrypt(String plaintext) {
  try {
   return new BASE64Encoder().encode(ecipher.doFinal(plaintext.getBytes("UTF8")));
  } catch (Exception e) {
   throw new RuntimeException(e);
  }
 }

 public String decrypt(String ciphertext) {
  try {
   return new String(dcipher.doFinal(new BASE64Decoder().decodeBuffer(ciphertext)), 
     "UTF8");
  } catch (Exception e) {
   throw new RuntimeException(e);
  }
 }
}

Java の KeyStore

次は、暗号鍵について検討します。Java プラットフォームのコア・ライブラリーを使用すれば、強力な暗号鍵を作成することができます。ただし、コア・ライブラリーのメソッドは毎回ランダムに新しい鍵を生成するため、Java の KeyGenerator クラスを使って鍵を作成したら、その鍵を後で使用するために (つまり、その鍵で暗号化されたテキストを復号するときまで) 保管しておかなければなりません。そのためには、Java プラットフォームの KeyStore ユーティリティーおよび対応するクラスを使用することができます。

KeyStore ユーティリティーに含まれる一連のクラスを使うことによって、パスワードで保護されたバイナリー・ファイル (鍵ストア) に鍵を保存することができます。Java では、わずかな数のテスト・ケースで鍵をテストできるようになっています。まずは、Key のインスタンスを 2 つ作成し、それぞれのインスタンスが異なる String に暗号化されることを明らかにします (リスト 4 を参照)。

リスト 4. 2 つの異なる鍵を使用した単純な暗号化
@Test
public void testEncryptRandomKey() throws Exception {
 SecretKey key = KeyGenerator.getInstance("AES").generateKey();
 Cryptographical crypto = AESCryptoImpl.initialize(new AESCryptoKey(key));
 String enc = crypto.encrypt("Andy");
 Assert.assertEquals("Andy", crypto.decrypt(enc));

 SecretKey anotherKey = KeyGenerator.getInstance("AES").generateKey();
 Cryptographical anotherInst = AESCryptoImpl.initialize(new AESCryptoKey(anotherKey));
 String anotherEncrypt = anotherInst.encrypt("Andy");
 Assert.assertEquals("Andy", anotherInst.decrypt(anotherEncrypt));

 Assert.assertFalse(anotherEncrypt.equals(enc));
}

続いてリスト 5 では、特定の鍵インスタンスが対応する String を暗号化すると、その結果は常に同じテキストになることを実証します。

リスト 5. 単一の文字列に対応する秘密鍵
@Test
public void testEncrypt() throws Exception {
 SecretKey key = KeyGenerator.getInstance("AES").generateKey();

 KeyStore ks = KeyStore.getInstance("JCEKS");
 ks.load(null, null);
 KeyStore.SecretKeyEntry skEntry = new KeyStore.SecretKeyEntry(key);
 ks.setEntry("mykey", skEntry, 
   new KeyStore.PasswordProtection("mykeypassword".toCharArray()));
 FileOutputStream fos = new FileOutputStream("agb50.keystore");
 ks.store(fos, "somepassword".toCharArray());
 fos.close();

 Cryptographical crypto = AESCryptoImpl.initialize(new AESCryptoKey(key));
 String enc = crypto.encrypt("Andy");
 Assert.assertEquals("Andy", crypto.decrypt(enc));

 //alternatively, read the keystore file itself to obtain the key

 Cryptographical anotherInst = AESCryptoImpl.initialize(new AESCryptoKey(key));
 String anotherEncrypt = anotherInst.encrypt("Andy");
 Assert.assertEquals("Andy", anotherInst.decrypt(anotherEncrypt));

 Assert.assertTrue(anotherEncrypt.equals(enc));
}

特定の鍵で暗号化したものは、同じ鍵を使って復号しなければなりません。Java の KeyStore を使用することが、鍵を保管するのに便利で安全な方法となります。

鍵ストアに関する注意事項

リスト 4リスト 5 のコードはボイラープレート・コードですが、以下の点を明らかにしてくれます。

  • 鍵ストアには名前があること。
  • 保管されるファイルは、パスワードで保護されること。
  • 鍵ストアには複数の鍵を保管できること。
  • 鍵ストアに保管される鍵ごとに、パスワードが関連付けられること。

このテスト・ケースでは、テストを実行するたびに新しい鍵ストアを作成することにしました。新しいテストのたびに既存の鍵ストアを開くのも難しい話ではありませんが、既存の鍵ストアを使用する場合、その鍵ストアのパスワードだけでなく、特定の鍵にアクセスするためのパスワードも必要であるため、ここでは新しい鍵ストアを作成することにしました。

暗号化では、鍵がすべてです。使われている暗号がいかに強力であるかは関係ありません。いかに強力な暗号でも、鍵のセキュリティーが侵害されたとしたら、データは暴露されてしまいます。これは、鍵ストアとそれに関連付けられたパス・フレーズを常にセキュアに保たなければならないということでもあります (例えば、本番アプリケーションでは、私はリスト 4リスト 5 のデモ・コードのようにパスワードをハード・コーティングすることはしません)。


クラウドでの暗号

データを暗号化すると、データのプロパティーが変更されます。つまり、暗号化された整数は、基本的に整数同士の比較にきちんと対応しなくなってしまいます。そのため、クラウドに保管されたデータに対して、どのような環境下で、どういう理由で、どのような方法を用いてクエリーを実行することになるかを十分に検討することが重要になります。幸いにも多くの場合、秘密にしておきたいデータには、操作したいデータとは異なるビジネス価値があります。例えば、口座名義人の名前や何らかの個人情報を暗号化するのは理にかなっていますが、口座残高の暗号化についてはそうとも言えません (個人に結び付けられない口座残高が、誰の関心を引くでしょうか)。

暗号化を使用したクエリーの実行

暗号化されたデータは、例えば「foo という名前のすべてのアカウントを検索する (ただし、foo は暗号化されている)」といった「完全」一致であれば簡単に検索することができます。一方、「支払遅延額が $450 を超えているすべてのアカウントを検索する (ただし、$450 は暗号化されている)」というような条件付きクエリーとなると、そのままでは上手く検索することができません。

例えば、単純な暗号として、「文字を逆順に並び替えた上で文字列の終わりに文字 i を追加する」暗号を使用するとします。この暗号化では、文字列 foo は oofi となり、450 は 054i となります。この単純な暗号を使用してテーブル内の名前の値が暗号化されている場合、完全一致 (例えば、「select * from table where name = 'oofi'」) によるクエリーは簡単に実行することができますが、450 という値を暗号化して比較するとなると、まったく別の話です。「select * from table where amount > 054i」と「select * from table where amount > 450」は、同じクエリーであるとは言えません。

この例でデータの比較を行うには、アプリケーションで何らかの復号を行う必要が出てきます。つまり、テーブルからすべてのデータを選択し、amount フィールドを復号してから、データを比較しなければなりません。このようなアクティビティーの場合、データ・ストアのデータをそのまま利用することはできないため、フィルタリングはデータ・ストアで行う場合ほど高速には行われません。効率を最大限に高めたいのであれば、どのデータを暗号化する必要があるのか、そしてどのように暗号化する必要があるのかを慎重に考えなければなりません。プログラムの全体的な効率を向上させるためには、将来行うことになるクエリーを念頭に暗号化することが有効な方法となります。

MongoDB 内のアカウント名を暗号化して、暗号化された名前を基準にアカウントを検索するのは簡単です (リスト 6 を参照)。

リスト 6. MongoDB での暗号化
@Test
public void encryptMongoDBRecords() throws Exception {
 KeyStore.SecretKeyEntry pkEntry = getKeyStoreEntry();
 Cryptographical crypto = 
   AESCryptoImpl.initialize(new AESCryptoKey(pkEntry.getSecretKey()));

 DB db = getMongoConnection();
 DBCollection coll = db.getCollection("accounts");

 BasicDBObject encryptedDoc = new BasicDBObject();
 encryptedDoc.put("name", crypto.encrypt("Acme Life, LLC"));
 coll.insert(encryptedDoc);


 BasicDBObject encryptedQuery = new BasicDBObject();
 encryptedQuery.put("name", crypto.encrypt("Acme Life, LLC"));

 DBObject result = coll.findOne(encryptedQuery);
 String value = result.get("name").toString();
 Assert.assertEquals("Acme Life, LLC", crypto.decrypt(value));
}

リスト 6 では最初のステップとして、getKeyStoreEntry メソッドを使用して既存の鍵ストアを読み取ります。次に、MongoDB インスタンスとの接続を取得します。この例での MongoDB インスタンスは、たまたま MongoHQ でホストされているクラウドにあります。続いて accounts コレクション (RDBMS プログラマーなら、アカウント・テーブルと呼ぶでしょう) へのリンクを取得し、新規アカウント・レコードをそれに対応する暗号化された名前と一緒に挿入します。最後に、挿入したそのレコードを検索するために、検索文字列を暗号化します (そのレコードでは、name は暗号化された “Acme Life, LLC” になっています)。

MongoDB に保管されたレコードは、リスト 7 に記載するような内容になっています (暗号化に使用する鍵は異なるため、皆さんが “Acme Life, LLC” を暗号化した文字列は、私が暗号化した文字列とは同じにならないことに注意してください)。

リスト 7. MongoDB 暗号化のテスト・ケース
{
 _id : "4ee0c541300484530bf9c6fa",
 name : "f0wJxYyVhfH0UkkTLKGZng=="
}

この文書では、実際の鍵 (name) は暗号化しないまま使用されていますが、この鍵についても暗号化することができます。鍵を暗号化するとしたら、対応するクエリーに必要なのはその変更を反映することだけです。また、コレクション名を暗号化することもできます。暗号化されているかどうかに関わらず、String の直接比較は上手く行くはずです。

この戦略を適用できるのは、MongoDB の実装だけではありません。例えば、ほぼ同じようなテスト・ケースを SimpleDB で実行することができます (リスト 8 を参照)。

リスト 8. SimpleDB での暗号化のテスト・ケース
@Test
public void testSimpleDBEncryptInsert() throws Exception {

 KeyStore.SecretKeyEntry pkEntry = getKeyStoreEntry();
 Cryptographical crypto = 
   AESCryptoImpl.initialize(new AESCryptoKey(pkEntry.getSecretKey()));

 AmazonSimpleDB sdb = getSimpleDB();
 String domain = "accounts";
 sdb.createDomain(new CreateDomainRequest(domain));

 List<ReplaceableItem> data = new ArrayList<ReplaceableItem>();

 String encryptedName = crypto.encrypt("Acme Life, LLC");

 data.add(new ReplaceableItem().withName("account_02").withAttributes(
  new ReplaceableAttribute().withName("name").withValue(encryptedName)));

 sdb.batchPutAttributes(new BatchPutAttributesRequest(domain, data));

 String qry = "select * from " + SimpleDBUtils.quoteName(domain) 
   + " where name = '" + encryptedName + "'";

 SelectRequest selectRequest = new SelectRequest(qry);
 for (Item item : sdb.select(selectRequest).getItems()) {
  Assert.assertEquals("account_02", item.getName());
 }
}

上記では、MongoDB の例と同じステップに従いました。つまり、既存の鍵ストアから読み取り、Amazon の SimpleDB との接続を取得した後、name 属性を暗号化したアカウント・レコードを挿入します。そして最後に、名前を基準にアカウントを検索するために、暗号化された値をその鍵として使用しています。


まとめ

クラウド・コンピューティングによって、広範なユーザーがデータにアクセスできることが約束されますが、それと同時に、機密データを保護するためにできることは沢山あります。この記事では、Java プラットフォームのライブラリーを使用して MongoDB や SimpleDB などのクラウド・インフラストラクチャーに保存されているデータをセキュアに保つ方法を説明しました。秘密鍵による暗号化では、データのセキュリティーは、そのデータの管理者の手に委ねられます。秘密鍵を Java の KeyStore に保管すれば、秘密鍵の管理が可能になり、安全が確保されます。秘密鍵にアクセスするためのパスワードは 1 つしかありません。決してやってはならないことは、パスワードを平文のままクラウドのどこかに保管することです。

検索のコンテキストによっては、暗号化された状態で保管されたデータは、平文のデータとは異なる振る舞いをします。完全一致は問題なく検索できますが、完全一致ではない条件付きクエリーは頭痛の種になりがちです。その場合のソリューションは、比較を処理する (あるいは処理しない) 方法にあります。常に、意図するクエリーを念頭に置いて、どのデータを暗号化するかをじっくり考えてください。すべてのデータを暗号化するまでのことはありません。クエリーの対象とその方法を検討することが重要となります。

参考文献

学ぶために

  • 連載「Java 開発 2.0」: この dW の連載では Java 開発の様相を塗り替える技術を詳しく探っています。これまで、Hadoop MapReduce (2011年1月)、Objectify-Appengine (2010年11月)、MongoDB (2010年9月)、SimpleDB (2010年6月) などの技術を話題に取り上げました。
  • Java security: Java security, Part 1: Crypto basics」(Brad Rubin 著、2002年7月): Java プラットフォームは、セキュア・アプリケーションを作成するための優れた基盤となります。暗号方式の基礎と、Java プログラミング言語で暗号化を実装する方法を学んでください。
  • 特権を委譲してクラウドのセキュリティーを強化する」(Jim Zierick 著、developerWorks、2011年12月): データ・センターをクラウドにマイグレーションする場合について、そしてクラウド・コンピューティングにおいてセキュリティーおよびコンプライアンスが持つ意味について検討しています。
  • ナレッジ・パス「Building an effective cloud policy」(developerWorks、2011年11月): 一連のアプリケーションを実行するフレームワーク (インフラストラクチャー、セキュリティー、パフォーマンス、または公開対話のフレームワーク) を定義するポリシーの作成方法を学んでください。
  • Big iron lessons, Part 5: Introduction to cryptography, from Egypt through Enigma」(Sam Siewert、developerWorks、2005年7月): 楽しみながら、暗号方式の詳細を学んでください。このチュートリアルでは、独自のペーパー・エニグマ・エンコーダーを作成する手順を説明した後、そのアクションを再現するソース・コードを詳しく探ります。
  • ナレッジ・パス「Using NoSQL and analyzing big data」(developerWorks、2011年5月): NoSQL、ビッグ・データ、そしてデータ・マイニングについて学ぶための dW リソースが揃っています。
  • Java Technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。
  • developerWorks Java technology ゾーン: Java プログラミングのあらゆる側面を網羅した記事が豊富に用意されています。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, Cloud computing
ArticleID=794214
ArticleTitle=Java 開発 2.0: クラウド・コンピューティング用の Java アプリケーション・データをセキュアにする
publish-date=02232012