La seguridad de la cuadrícula de datos garantiza que un servidor que se una tenga las credenciales adecuadas, de manera que un servidor malintenciado no se pueda unir a la cuadrícula de datos. La seguridad de la cuadrícula de datos utiliza un mecanismo de serie secreta compartida.
Todos los servidores WebSphere eXtreme Scale, incluidos los servidores de catálogo, acuerdan una serie secreta compartida. Cuando un servidor se une a la cuadrícula de datos, se solicita que proporcione la serie secreta. Si la serie secreta del servidor que se une coincide con la serie del servidor presidente o el servidor de catálogo, se acepta el servidor que se une. Si la serie no coincide, se rechaza la solicitud de unión.
El envío de una serie secreta en texto normal no es seguro. La infraestructura de seguridad de WebSphere eXtreme Scale proporciona un plug-in de gestor de señales seguras para permitir al servidor proteger este secreto antes de enviarlo. Debe decidir cómo implementar la operación segura. WebSphere eXtreme Scale proporciona una implementación directa, en la que la operación segura se implementa para cifrar y firmar el secreto.
La serie secreta se establece en el archivo server.properties. Consulte Archivo de propiedades de servidor si desea más información sobre la propiedad authenticationSecret.
Un plug-in de gestor de señales seguras se representa mediante la interfaz com.ibm.websphere.objectgrid.security.plugins.SecureTokenManager.
Si desea más información sobre el plug-in SecureTokenManager, consulte la documentación de la API SecureTokenManager.
El método generateToken(Object) toma un objeto y, a continuación, genera una señal que no los otros no pueden entender. El método verifyTokens(byte[]) realiza el proceso inverso: el método convierte la señal en el objeto original.
Una implementación sencilla de SecureTokenManager utiliza un algoritmo de codificación sencillo, como un algoritmo exclusivo o (XOR), para codificar el objeto en un formato serializado y, a continuación, utilizar el algoritmo de decodificación correspondiente para descifrar la señal. Esta implementación no es segura.
WebSphere eXtreme Scale proporciona una implementación disponible de forma inmediata para esta interfaz.
La implementación predeterminada utiliza un par de claves para firmar y verificar la firma, y utiliza una clave secreta para cifrar el contenido. Cada servidor tiene un almacén de claves de tipo JCKES donde se almacena el par de claves, una clave privada y una clave pública, y un clave secreta. El almacén de claves tiene que ser de tipo JCKES para poder almacenar las claves secretas.
Estas claves se utilizan para cifrar y firmar o verificar la serie secreta en el envío. Además, la señal se asocia con un tiempo de caducidad. En el extremo receptor, los datos se verifican, se descifran y se comparan con la serie secreta del receptor. Los protocolos de comunicación SSL (Secure Sockets Layer) no son obligatorios para la autenticación entre un par de servidores porque las claves privadas y públicas sirven para ese mismo propósito. No obstante, si la comunicación del servidor no está cifrada, los datos podrían robarse con sólo observar la comunicación. Como la señal caduca pronto, la amenaza de ataque de reproducción se minimiza. Esta posibilidad disminuye en gran medida si todos los servidores se despliegan detrás de un cortafuegos.
La desventaja de este enfoque es que los administradores de WebSphere eXtreme Scale deben generar claves y transportarlas a todos los servidores, que puede provocar una violación de seguridad durante el transporte.
Como se ha indicado en la sección anterior, puede crear un almacén de claves que contenga un par de claves para firmar y verificar la firma y una clave secreta para cifrar el contenido.
Por ejemplo, puede utilizar el mandato keytool de JDK 6 para crear las claves tal como se indica a continuación:
keytool -genkeypair -alias keypair1 -keystore key1.jck -storetype JCEKS -keyalg
rsa -dname "CN=sample.ibm.com, OU=WebSphere eXtreme Scale" -storepass key111 -keypass
keypair1 -validity 10000
keytool -genseckey -alias seckey1 -keystore key1.jck -storetype JCEKS -keyalg
DES -storepass key111 -keypass seckey1 -validity 1000
Estos dos mandatos crean a un par de claves "keypair1" y una clave secreta "seckey1".
Luego puede configurar lo siguiente en el archivo de propiedades del servidor:secureTokenKeyStore=key1.jck
secureTokenKeyStorePassword=key111
secureTokenKeyStoreType=JCEKS
secureTokenKeyPairAlias=keypair1
secureTokenKeyPairPassword=keypair1
secureTokenSecretKeyAlias=seckey1
secureTokenSecretKeyPassword=seckey1
secureTokenCipherAlgorithm=DES
secureTokenSignAlgorithm=RSA