Proteger secretos con las funciones de la plataforma

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

Enumerar las opciones y prácticas recomendadas para almacenar secretos dentro de paquetes gestionados
Crear credenciales con nombre para definir de manera segura extremos de llamadas y sus parámetros de autenticación asociados
Describir la forma en que se pueden aprovechar la configuración personalizada protegida y los campos de API de metadatos personalizados protegidos para almacenar secretos

Almacenar secretos de aplicaciones en Salesforce

En la primera unidad aprendimos cómo identificar secretos y quiénes deberían tener acceso a ellos. El siguiente paso es aprender a protegerlos.

Esto es sencillo. La plataforma Salesforce tiene diversas funciones que se pueden utilizar para almacenar y proteger secretos. Estas funciones son:

Credenciales con nombre
La configuración personalizada (protegida, desprotegida, no gestionada y gestionada)
Tipos de metadatos personalizados

En esta unidad, explicamos cada una de estas opciones para almacenar secretos con el fin de garantizar que la información confidencial se restrinja de forma apropiada.

Credenciales con nombre

Una credencial con nombre especifica la URL de un extremo de llamada y sus parámetros de autenticación requeridos en una definición. Salesforce gestiona toda la autenticación para las llamadas de Apex que especifican una credencial con nombre como extremo de llamada y no tiene que agregar más lógica de autenticación a su código Apex. Es posible definir credenciales con nombre para proporcionar una forma segura y cómoda de configurar estos tipos de llamadas. Una vez creadas, es posible sustituir las referencias de URL de su código por referencias a credenciales con nombre, las cuales proporcionan un código más limpio, sencillo y seguro.

Las credenciales con nombre son particularmente útiles en el momento de definir extremos de llamadas a los que se hace referencia en su paquete gestionado. Sin ellas, para configurar una llamada autenticada, el desarrollador tiene que realizar estas tareas adicionales.

Hacer referencia a la URL como el extremo de llamada
Registrar la URL en su configuración de sitio remoto
Incorporar código personalizado para que se encargue de todas las tareas de autenticación asociadas

Por ejemplo, digamos que tiene una aplicación que conecta de forma habitual con un servicio externo para extraer datos. Sin embargo, este servicio externo requiere que cada solicitud incluya una clave de API para la autenticación. Un método común que los desarrolladores usan para cumplir con este requisito es incluir esa clave en el código fuente para que se pueda utilizar en cada solicitud. Consulte el siguiente ejemplo de código.

String key = ‘supersecurepassword’;
HttpRequest req = new HttpRequest();
req.setEndpoint('https://www.example.com/test?APIKEY='+key);
req.setMethod('GET');
Http http = new Http();
HTTPResponse res = http.send(req);
return res.getBody();

Si bien la codificación de secretos es efectivamente una solución directa, existen tres problemas principales con este enfoque.

Cualquiera que pueda ver el código fuente puede ver también los secretos incrustados.
Si se actualiza un secreto, tendrá que cambiar todas las instancias de éste en todo el código fuente.
Portar este secreto entre aplicaciones puede crear muchas otras complicaciones.

¡Aquí es donde las credenciales con nombre pueden aportarnos la solución! En lugar de codificar el valor en su código, puede aprovechar las credenciales con nombre para almacenar secretos, lo que permite hacer referencia a la credencial con nombre para acceder al valor secreto, como si fuese otra variable de su código.

Si utiliza una credencial con nombre en vez del valor en sí, solo los usuarios con el perfil Administrador del sistema y aquellos con los permisos Ver todos los datos y Modificar todos los datos pueden acceder al valor.

Beneficios de las credenciales con nombre

Además de proporcionar un método para restringir el acceso a los secretos de sus aplicaciones, las credenciales con nombre también facilitan mucho el mantenimiento de estos secretos. Tras configurar una credencial con nombre, puede cambiarla fácilmente siempre que sea necesario modificándola en su configuración. De esta manera, cualquier instancia de su código que haga referencia al secreto nunca retendrá valores obsoletos, ya que hacen referencia a la credencial con nombre directamente.

Dónde usar las credenciales con nombre

Si bien es bastante simple configurar las credenciales con nombre, no son necesariamente una buena solución para todos los casos de uso. Las credenciales con nombre son apropiadas para los esquemas de autenticación simples como OAuth 2.0 o el nombre de usuario y la contraseña.

Las credenciales con nombre se diseñaron para hacer la vida de los administradores y desarrolladores fácil y segura en su organización. Dicho esto, no siempre son la mejor elección. Debido a que los usuarios con el permiso Modificar todos los datos o Apex de autor pueden modificar o realizar llamadas a la credencial con nombre, también pueden acceder a los datos protegidos por la credencial con nombre. O bien, pueden extraer las credenciales ellos mismos. Si necesita protección contra estos casos de uso (por ejemplo, si es un proveedor de software independiente que está creando un paquete y necesita hablar de forma privada con sus propios servicios de nube), considere otras opciones como la configuración personalizada protegida gestionada o los tipos de metadatos personalizados protegidos gestionados. En la siguiente sección, puede leer más sobre esas opciones.

Asegurar secretos distribuidos

Las credenciales con nombre son perfectas para situaciones donde se están realizando llamadas a servicios externos en una organización donde se permite a los administradores acceder a los secretos de autenticación asociados. ¿Pero qué hacer cuando tiene que evitar que los administradores vean los datos, o cuando desea distribuir secretos entre múltiples organizaciones de Salesforce?

En situaciones como esta, el código debe implementarse en forma de paquete gestionado. Puede iniciar de forma gratuita una organización de Developer Edition que le servirá como organización de empaquetado para su código. Si es socio de AppExchange, puede crear organizaciones de Developer Edition a través de su núcleo de entorno. También puede visitar la página de inscripción en Developer Edition. Dentro de su organización de empaquetado, puede incluir clases de Apex, desencadenadores de Apex, objetos de Salesforce y otras formas comunes de metadatos en un paquete gestionado, lo que permite su sencilla implementación en cualquier otra instancia u organización de Salesforce. Puede considerar un paquete gestionado como una versión más compleja de un archivo Zip.

Desde la perspectiva de la seguridad, los paquetes gestionados (en contraposición a los paquetes no gestionados o el código suelto) aportan muchos beneficios significativos.

Estos tienen la mecánica necesaria para distribuir parches, correcciones y actualizaciones automáticas si se identifican vulnerabilidades de seguridad.
Tienen código fuente opaco (a excepción de las clases de Apex expuestas de forma explícita), lo cual significa que ninguna lógica de negocio o programa fundamental puede alterarse de forma inadvertida ni modificarse de manera malintencionada y redistribuirse. El código opaco también evita que los secretos que contiene el paquete sean vistos.
Debido a que debe definir un espacio de nombres exclusivo para su paquete gestionado, evita problemas de espacios de nombres en conflicto. También separa su paquete del espacio de nombres local, lo cual protege aún más los secretos que contiene el paquete. De manera predeterminada, no es posible acceder a los secretos de paquetes mediante código que se ejecute fuera del paquete gestionado.

Gestionar configuraciones personalizadas y tipos de metadatos personalizados protegidos

Aunque solo empaquetando su código en un paquete gestionado tiene gran número de beneficios de seguridad, el uso de un paquete gestionado también ofrece acceso a otras dos funciones disponibles para almacenar y distribuir información: la configuración personalizada protegida y los metadatos personalizados protegidos.

Se puede crear una configuración personalizada para almacenar casi cualquier tipo de datos. Es una opción extremadamente flexible en términos de usos y contenido potenciales. En resumen, la configuración personalizada le permite crear conjuntos de datos personalizados que quedan expuestos a la caché de aplicaciones, de modo que evita realizar consultas repetidas a la base de datos y aumenta la eficiencia de su aplicación. Por ejemplo, una configuración personalizada puede utilizarse para almacenar un conjunto de datos que se utilice para personalizar experiencias de usuarios con una aplicación. O quizá puede crearse una configuración personalizada para almacenar una lista de nombres de productos a los que se haga referencia en muchas páginas diferentes, con el fin de proporcionar un acceso rápido y sencillo. En lo referente a la seguridad de las aplicaciones, la configuración personalizada puede emplearse para almacenar información confidencial o secretos.

La configuración personalizada puede tener diferentes niveles de visibilidad. Una configuración personalizada protegida contenida en un paquete gestionado no es visible a las organizaciones suscriptoras a través de Apex o la API, lo que la convierte en un buen lugar para almacenar ciertos tipos de secretos. Una configuración personalizada establecida para la visibilidad pública o incluida en un paquete no gestionado es visible a través del lenguaje de descripción de servicios web (WSDL) para compañías. Por lo tanto, es importante encapsular la configuración personalizada en un paquete gestionado si esta aloja información confidencial.

Los campos de metadatos personalizados pueden utilizarse para el almacenamiento de secretos de forma parecida a la configuración personalizada. Para una confidencialidad adecuada, establezca su visibilidad en “Protegida” e inclúyalos en un paquete gestionado. Los campos de API de metadatos personalizados son una excelente elección para almacenar claves de API u otras claves de secretos, por ejemplo.

En referencia a la configuración de la visibilidad, tanto la configuración personalizada como los campos de metadatos tienen varias opciones.

Pública (local)
Protegida (local)
Pública (gestionada)
Protegida (gestionada)

Mientras que las primeras tres opciones son viables para almacenar datos en general, todo el mundo en la organización puede ver valores de datos cuando utiliza estos parámetros. Utilícelos únicamente cuando esté almacenando datos accesibles de forma pública. Para los datos confidenciales, como los secretos de aplicaciones, utilice la opción de configuración de protección gestionada.

La opción de visibilidad opaca, la facilidad de acceso y las funciones de caché hacen que la configuración personalizada y los campos de metadatos sean opciones viables y atractivas para el almacenamiento de secretos.

Crear una configuración personalizada protegida gestionada

Puede crear una configuración personalizada protegida gestionada denominada Secretos de distrito que se pueda utilizar para almacenar secretos de manera segura. Para crear una configuración personalizada protegida, en Configuración, vaya a Búsqueda rápida > Configuración personalizada y haga clic en Nueva. Defina una etiqueta, el nombre de objeto, el tipo de configuración y la visibilidad (establezca esta última en Protegida). Una vez que haga clic en Guardar, estará listo para agregar campos personalizados para almacenar los secretos.

Captura de pantalla de la configuración personalizada. Computadora portátil abierta en la página Definición de configuración personalizada con campos para Etiqueta, Nombre de objeto, Tipo de configuración, Visibilidad y Descripción.

Finalmente, ingrese sus secretos dentro de sus campos personalizados protegidos. Debido a que solo se incluyen en el paquete las definiciones de la configuración, necesita una secuencia de comandos Apex o API para rellenar los secretos una vez que se instale el paquete en la organización de destino o suscriptor.

Cómo utilizar la configuración personalizada protegida gestionada

Puede hacer referencia a la configuración personalizada de las mismas formas que emplea para hacer referencia a objetos personalizados. Para acceder a la configuración personalizada, puede utilizar campos de fórmula, métodos de configuración personalizada de Apex, la API de SOAP, reglas de validación, etcétera. Las referencias a la configuración personalizada protegida solo pueden realizarse desde el mismo paquete gestionado, es decir, el mismo espacio de nombres. Algunos métodos de Apex comunes para hacer referencia a configuraciones personalizadas son:

getAll()
getValues()
getOrgDetails()
getInstance(Profile_ID)

A continuación, se muestra un ejemplo que utiliza getAll() para acceder a los secretos almacenados como un componente de configuración personalizada.

Map<String, CustomSettingName__c> mcs = CustomSettingName__c.getAll();

Tipos de metadatos personalizados

También se pueden definir tipos de metadatos personalizados protegidos para albergar secretos de igual modo que se define una configuración personalizada. Como explicamos, los tipos de metadatos personalizados deben estar diseñados para su inclusión en un paquete gestionado a fin de poder ocultarlos y protegerlos de forma eficiente. La diferencia principal es que los datos contenidos en tipos de metadatos personalizados representan los metadatos de su aplicación.

A menudo, esto puede ser una ventaja. Imagine que usted es un desarrollador que está creando una nueva aplicación en su organización de empaquetado de Developer Edition. Esta aplicación tiene diversidad de interesantes funciones, incluyendo una integración de API externa con example.com. Para realizar llamadas a example.com, necesita almacenar una clave de API en algún lugar. Una opción es almacenar la clave secreta de API dentro de un campo personalizado. Esto funciona bien dentro de su propia organización de DE, pero ¿dónde falla este enfoque?

Además de ser una solución poco segura, existe un problema con el almacenamiento de la clave secreta de API dentro de un campo personalizado cuando se trata de una reimplementación. Cuando intenta trasladar todo su código y personalizaciones a su organización de producción, el valor de su clave secreta no se distribuye al mismo tiempo. Los datos no se transfieren a producción junto con el conjunto de cambios. Tiene que insertar el valor de la clave en el campo de forma manual o es necesario redactar una secuencia de comandos para rellenarlo por usted. Por otro lado, con un tipo de metadatos personalizados, la clave secreta de API se trata como cualquier otra personalización y se traslada a producción. En esta situación, no necesita insertarla de nuevo usted mismo.

Recuerde que, para cargar datos en una configuración personalizada, debe escribir algún tipo de secuencia de comandos posterior a la instalación. Pero no tiene que escribir secuencias de comandos con los tipos de metadatos personalizados protegidos. Los datos que contiene un tipo de metadatos personalizados están disponibles para usted como metadatos separados, que puede incorporar al paquete. Eso no está nada mal, ¿verdad?

Uno de los aspectos más interesantes sobre los tipos de metadatos personalizados es que se pueden captar mediante SOQL, tal como ocurre con cualquier objeto personalizado. La única diferencia es que los tipos de metadatos tienen un sufijo __mdt en vez de __c. Si necesita seleccionar un tipo de metadatos personalizados, escriba una consulta de la siguiente manera:

SELECT Teacher__c, Coach__c, Counselor__c , Administrator__c FROM District_Profiles__mdt

Esta línea recupera todos los valores de District_Profiles__mdt. ¡Eso es bastante fácil!

Comparación de configuraciones personalizadas y tipos de metadatos personalizados

Aunque puede utilizar configuraciones personalizadas o tipos de metadatos personalizados para asegurar secretos, existen algunas diferencias entre los dos que merece la pena mencionar. Repasemos cuándo usar cada uno.

Utilice configuraciones personalizadas protegidas cuando:

Sea necesario actualizar el secreto con frecuencia y este deba estar disponible de inmediato. Como los tipos de metadatos deben colocarse en cola e implementarse, los secretos actualizados en los tipos de metadatos no se encuentran disponibles al instante. En este caso, la configuración personalizada es una mejor opción.
Desee especificar qué perfiles y usuarios pueden acceder a qué secretos. Los tipos de metadatos no ofrecen la granularidad de los tipos de jerarquías de configuración personalizada, en los que se puede especificar para qué perfiles o usuarios deben estar disponibles los secretos. Por ello, es mejor utilizar aquí una configuración personalizada.

Utilice los tipos de metadatos personalizados cuando:

Desee implementar un secreto común sin tener que realizar pasos de configuración adicionales.
Los secretos de metadatos personalizados pueden migrarse con facilidad, por ejemplo, desde un entorno aislado o de desarrollo hacia un entorno de producción. En cambio, en las configuraciones personalizadas, los administradores deben escribir secuencias de comandos posteriores a la instalación o crear páginas, ingresar manualmente los secretos y almacenarlos en el nuevo entorno.