MongoDB Inicio
Dependencia
La siguiente dependencia se proporciona por defecto para proyectos basados en flo (creados utilizando el Andamio)
<dependency>
<groupId>com.iconsolutions.ipf.core.platform</groupId>
<artifactId>ipf-common-starter-mongo</artifactId>
</dependency>
Si está desarrollando su propio proyecto utilizando MongoDB como un almacén de datos y utilizando Spring Reactive, puede incluir la dependencia anterior para proporcionar una mejora MongoDB integración.
Hacerlo añade:
-
Reintentos
-
Configuración de SSL
-
Convertidores Adicionales
-
Verificación de Salud de Mongo Caching
Esta página describe las diversas opciones de configuración para la funcionalidad proporcionada por la dependencia mencionada anteriormente.
Reintentos
Al utilizar el MongoDB El iniciador, la configuración de reintento predeterminada a continuación ayuda a manejar fallos transitorios (como problemas de red o límites de tasa) en los Repositorios Reactivos de Spring Data y puede ser customised según sea necesario.
| Config | Tipo | Comentario | Predeterminado |
|---|---|---|---|
|
Entero |
Número máximo de intentos de reintento si el código de error está contenido en la lista de |
|
|
Lista de Enteros |
Lista de códigos de error separados por comas para los cuales se deben intentar reintentos. |
|
|
Duración |
Retraso hasta el próximo intento de reintento, especificado como una duración. Para más detalles sobre el formato soportado, consulte:https://github.com/lightbend/config/blob/main/HOCON.md#duration-format |
|
Configuración de SSL
Si asegura una conexión a MongoDB servidor, esto puede hacerse configurando la siguiente configuración.
| Config | Tipo | Comentario | Predeterminado | ||
|---|---|---|---|---|---|
|
Boolean |
Configure el contexto SSL basado en los parámetros de configuración a continuación. |
|
||
|
Cadena |
Ruta del archivo o ubicación del recurso del archivo keystore para MongoDB Conexiones SSL/TLS |
|
||
|
Cadena |
Se requiere una contraseña para acceder al almacén de claves definido por
|
|
||
|
Cadena |
El tipo de almacén de claves definido por |
|
||
|
Cadena |
Especifica la contraseña requerida para acceder a la clave privada dentro del almacén de claves.
|
|
||
|
Cadena |
Ruta del archivo o ubicación del recurso del almacén de confianza utilizado para establecer confianza en las conexiones SSL/TLS a MongoDB |
|
||
|
Cadena |
El tipo de almacén de confianza definido por |
|
||
|
Cadena |
Contraseña para acceder al archivo de almacén de confianza.
|
|
Convertidores Adicionales
Los siguientes convertidores adicionales están registrados como MongoCustomConversions con Spring Data al agregar el ipf-common-starter-mongo dependencia:
| Convertidor | Conversión |
|---|---|
Decimal128To Big Decimal Converter |
|
Convertidor Big Decimal ADecimal128 |
`Decimal128`es un tipo bson de mongo |
DateToOffsetDateTimeConverter |
|
OffsetDateTimeToDateConverter |
|
DateToIsoDateTimeConverter |
|
ConvertidorIsoFechaHoraAString |
|
StringToIsoDateTimeConverter |
|
CommandIdToStringConverter |
|
StringToCommandIdConverter |
|
SupportingContextToStringConverter |
|
StringToSupportingContextConverter |
|
Verificación de Salud de Mongo Caching
Hay una limitación en el número de verificaciones de salud que se pueden realizar en MongoDB (CosmosDB): 1. 66 solicitudes de metadatos por segundo. Debido a esta limitación, se decidió introducir caching a nivel de MongoReactiveHealthIndicator. Por supuesto,caching reduce significativamente el número de solicitudes de obtención de metadatos hacia MongoDB.
| Es importante señalar que solo las solicitudes de salud exitosas son cached, lo que significa que el error o el resultado vacío no será cached. |
Este comportamiento está controlado por las siguientes propiedades:
ipf.mongodb.cacheable-health-indicator {
enabled = false // controlls if the caching is enabled
refresh-interval = 10s // allows client to chose refresh interval
}Cifrado a Nivel de Campo del Lado del Cliente (CSFLE)
IPF apoya MongoDB’s Cifrado a Nivel de Campo del Lado del Cliente(CSFLE). CSFLE es una característica de seguridad que cifra campos de datos sensibles especificados (por ejemplo, Información Personal Identificable) almacenados en la base de datos. Funciona de tal manera que la propia base de datos, junto con sus administradores, no puede ver los datos. Solo la aplicación que utiliza MongoDB para almacenar información puede ver los datos.
CSFLE va más allá de la encriptación estándar al garantizar que los datos estén encriptados antes de que lleguen a la base de datos; en otras palabras, es una forma de encriptación de extremo a extremo. Esto asegura que los datos permanezcan protegidos durante el tránsito, en rest, e incluso de administradores de bases de datos o acceso interno no autorizado. Mientras MongoDB proporciona cifrado incorporado en rest, que protege los datos almacenados en disco, CSFLE añade una capa adicional de seguridad. Con CSFLE, la encriptación y desencriptación ocurren completamente dentro de la aplicación cliente. Como resultado, solo las aplicaciones autorizadas pueden acceder a los datos originales. Incluso MongoDB en sí mismo, incluidos sus administradores de bases de datos y la infraestructura subyacente, no puede leer ni acceder a los campos cifrados.
Este enfoque ofrece varios beneficios clave:
-
Confidencialidad de Datos Mejorada: Los datos sensibles permanecen protegidos no solo en disco, sino también durante su transmisión y dentro del motor de la base de datos.
-
Protección contra Amenazas Internas: Los campos cifrados son ilegibles para los operadores internos y los usuarios privilegiados que de otro modo podrían tener acceso completo a la base de datos.
-
Preparación para el Cumplimiento: Ayuda a cumplir con los requisitos regulatorios y de cumplimiento, como el GDPR, HIPAA y PCI DSS, al imponer un control estricto sobre quién puede ver información sensible.
-
Cifrado Selectivo: Se pueden cifrar campos específicos—en lugar de registros completos—ofreciendo tanto precisión como rendimiento.
-
En resumen, CSFLE ofrece a las organizaciones un enfoque de confianza cero para la seguridad de los datos, donde la información sensible está protegida de extremo a extremo y es visible únicamente para los sistemas que realmente necesitan acceder a ella.
⚠️ Consideraciones Importantes ⚠️
Tenga en cuenta que las claves de cifrado CSFLE no son efímeras. Es decir, no se generan por sesión, sino que son de larga duración. En otras palabras, perder las claves de cifrado significa perder el acceso a sus datos.
Antes de comenzar a utilizar CSFLE, por favor asegúrese de que tiene procesos sólidos establecidos para gestionar claves y acceso a claves.
Aquí hay una lista no exhaustiva de cambios en la aplicación que requieren una consideración adicional cuando CSFLE está habilitado:
| Evento | Impacto |
|---|---|
Se ha perdido una clave de cifrado. |
Los datos no pueden ser recuperados. |
Una clave de cifrado está comprometida. |
Debe descifrar todos los campos que fueron cifrados con la clave comprometida, actualizarlos atómicamente con una nueva. valor encriptado derivado de una nueva clave no comprometida, y luego actualice IPF para utilizar el nuevo ID de clave. |
Un campo que anteriormente no se consideraba sensible ahora es sensible. |
Debe cifrar todas las instancias existentes del campo utilizando la nueva clave de cifrado y actualizar el esquema de cifrado IPF. incluir el nuevo campo. |
Configuración Básica
El fragmento a continuación muestra la configuración mínima requerida para configurar CSFLE para IPF:
ipf.mongodb.csfle {
enabled = true (1)
key-vault-namespace = "encryption.__keyVault" (2)
key-id = "fITzChBUQFWiAjyWAvvdbg==" (3)
kms-providers {
//pick the right one for your environment from one of local/aws/gcp/azure/kmip:
local { (4)
key = "key-here"
}
aws { (5)
accessKeyId = "key-id-here"
secretAccessKey = "secret-access-key-here"
}
gcp { (6)
email = "my@gcp.email"
privateKey = "my-private-key"
}
azure { (7)
tenantId = "tenant-id-here"
clientId = "client-id-here"
clientSecret = "client-secret-here"
}
kmip { (8)
endpoint = "my.kmip.com" //uses default KMIP port 5696
}
}
extra-options {
cryptSharedLibPath = "/path/to/mongo_crypt_v1.so" (9)
cryptSharedLibRequired = true
}
}| 1 | Habilite CSFLE (deshabilitado por defecto) |
| 2 | El espacio de nombres (database.collection) que contiene el almacén de claves |
| 3 | La clave ID de IPF compartida que debe utilizar (consulte [specifying-a-key-id] para el formato, y también Qué es la encriptación y cómo anular la clave de encriptación predeterminada) |
| 4 | Ejemplo de KMS local |
| 5 | Ejemplo de AWS KMS |
| 6 | Ejemplo de GCP KMS |
| 7 | Ejemplo de Azure KMS |
| 8 | Ejemplo de KMIP |
| 9 | Ruta al MongoDB biblioteca compartida de cifrado utilizada para cifrar los datos. Descargue aquí(seleccione crypt_shared bajo "Paquete")
=== Especificando un ID de clave |
Las identificaciones clave se especifican como el equivalente codificado en base64 de la _id de la clave. Esto suele ser un UUID. Por ejemplo, si
una entrada clave en el MongoDB el vault es:
{
_id: UUID('634211da-561d-4e34-b958-554b5bef3565')
//..other fields here..
}El ID de clave equivalente sería la versión codificada en base64 de los bytes representados por la cadena UUID (no el UUID). cadena en sí misma). A continuación, se presentan algunos fragmentos de código para convertir los bytes de un UUID a su equivalente en base64.
| Idioma | Fragmento |
|---|---|
Shell |
|
Java |
|
Python |
|
keyAltNames no son compatibles.
|
Qué es la encriptación y cómo anular la clave de encriptación predeterminada
Por defecto, solo una clave de datos (definida en key-id se requiere cifrar todos los campos. La tabla a continuación muestra todos
los campos que IPF Engineering ha identificado como potencialmente contenedores de datos de PI, y ha decidido cifrar si CSFLE es
habilitado.
La tabla también muestra la clave de configuración que puede establecer para utilizar un ID de clave diferente para cifrar cada campo. El formato general es
ipf.mongodb.csfle.mongodb.[collection].[field]:
| Colección | Campo a cifrar | Clave de configuración para anular la clave ID predeterminada |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cifrado de colecciones adicionales
Para cifrar colecciones adicionales, añada un encryption-schemas bloque de configuración bajo ipf.mongodb.csfle y utilice
el normal Esquemas de Cifrado sintaxis:
La única desviación de la MongoDB La referencia anterior es que no debe anteponer el nombre de la colección con el
nombre de la base de datos. IPF determinará esto automáticamente a partir de la ipf.mongodb.url.
|
ipf.mongodb.csfle {
//other config here e.g. KMS, shared lib path
encryption-schemas {
myCollection {
bsonType = "object"
properties {
myProperty {
bsonType = "string" (1)
keyId = [
{
"$binary" {
base64 = ${my-special-key-id} (2)
subType = "04"
}
}
]
algorithm = "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic" (3)
}
}
}
}
}Solución de problemas
CSFLE puede ser difícil de configurar. Aquí hay algunos mensajes de error comunes que puede encontrar en el registro y potenciales resoluciones:
| Error | Resolución |
|---|---|
o |
The |
|
Asegúrese de que |
|
La clave del proveedor KMS definida es diferente a la que se utilizó inicialmente para escribir datos en la base de datos. |