Preguntas frecuentes de Identity and Access Management

Temas de las preguntas frecuentes

General

¿Qué es Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)?

OCI IAM es un servicio nativo de OCI que proporciona funciones de gestión de identidad y acceso de clase empresarial, como autenticación compleja y adaptable, gestión del ciclo de vida (Lifecycle Management, LCM) del usuario y conexión única (Single Sign-On, SSO) a aplicaciones empresariales. OCI IAM se despliega como dominios de identidad en OCI. Los dominios incluidos permiten a las organizaciones gestionar el acceso a sus servicios de Oracle Cloud (red, recursos informáticos, almacenamiento, etc.) y aplicaciones de Oracle SaaS. Los clientes pueden elegir actualizar o crear dominios de identidad adicionales para adaptarse a otros casos de uso, como la gestión del acceso del personal a aplicaciones que no sean de Oracle, la activación del acceso del consumidor a aplicaciones orientadas al cliente o la incorporación de IAM en aplicaciones desarrolladas de forma personalizada.

¿Qué son los dominios de identidad?

Cada dominio de identidad de OCI IAM es una solución de gestión de identidad y acceso independiente que se puede utilizar para abordar una variedad de casos de uso de IAM. Por ejemplo, puedes utilizar un dominio de identidad de OCI IAM para gestionar el acceso de los empleados a numerosas aplicaciones locales y en la nube, lo que permite una autenticación segura, una gestión sencilla de los derechos y una SSO sin problemas para los usuarios finales. También puede que desees configurar un dominio de identidad para permitir el acceso a la cadena de suministro o a los sistemas de órdenes para los socios comerciales. También puedes utilizar dominios de identidad para activar IAM para aplicaciones orientadas al consumidor y permitir a los usuarios consumidores realizar autorregistros, conexión social o consentimientos de las condiciones de uso. Los dominios de identidad representan una solución completa de identidad como servicio (identity-as-a-service, IDaaS) que se adapta a numerosos casos de uso y escenarios de IAM.

¿Qué tipo de dominio de identidad debo elegir?

  • Dominios de identidad gratuitos: cada arrendamiento de OCI incluye un dominio de identidad de OCI IAM por defecto de cuenta gratuita para gestionar el acceso a los recursos de OCI (red, recursos informáticos, almacenamiento, etc.). Si solo deseas gestionar el acceso a los recursos de OCI, puedes utilizar el dominio por defecto incluido. Proporciona un sólido conjunto de funcionalidades de IAM para gestionar el acceso a los recursos de Oracle Cloud. Según el modelo de seguridad y el equipo, los clientes pueden optar por reservar este dominio para los administradores de OCI.
  • Dominios de identidad de Oracle Apps: numerosas aplicaciones de Oracle Cloud (HCM, CRM, ERP, aplicaciones del sector, etc.) pueden incluir el uso de OCI IAM a través de un dominio de aplicaciones de Oracle. Estos dominios se incluyen para su uso con aplicaciones de Oracle suscritas y proporcionan una funcionalidad de IAM sólida para gestionar el acceso a los servicios de Oracle Cloud y SaaS. Los clientes pueden elegir agregar todos los empleados a este dominio para activar SSO en un servicio de aplicación de Oracle Cloud y pueden utilizar este dominio para gestionar el acceso a algunos o todos sus recursos de OCI.
  • Dominios de identidad de Oracle Apps Premium: si deseas ampliar un dominio de Oracle Apps con funciones empresariales completas para gestionar el acceso de las aplicaciones de Oracle que pueden no entregarse mediante SaaS (p. ej., Oracle E-Business Suite u Oracle Databases, ya sean locales o alojadas en OCI), los dominios de Oracle Apps Premium ofrecen el conjunto completo de funciones y capacidades de OCI IAM para su uso con destinos de Oracle que se pueden desplegar en entornos de nube híbrida. Se trata de un servicio de bajo costo que cuenta con todas las funciones, pero que se limita al uso con destinos de Oracle.
  • Dominios de identidad externos: los dominios de identidad externos ofrecen un conjunto completo de funciones y capacidades de OCI IAM para no empleados, como consumidores que acceden a un sitio minorista, gobiernos que permiten el acceso a ciudadanos o empresas que permiten el acceso a socios comerciales. No hay restricciones sobre las aplicaciones que se pueden dirigir. Sin embargo, no se incluyen algunas funciones empresariales que normalmente no son útiles en escenarios de no empleados, como el gateway de aplicaciones y el puente de aprovisionamiento. Los dominios externos incluyen soporte para la conexión social, el autorregistro, el consentimiento de las condiciones de uso y la gestión de perfiles/contraseñas.
  • Dominios de identidad premium: los dominios de identidad premium ofrecen el conjunto completo de funciones y capacidades de OCI IAM sin restricciones en las aplicaciones a las que se pueden dirigir. Los dominios premium se pueden utilizar como un servicio de IAM empresarial que gestiona el acceso de empleados o personal a través de aplicaciones en la nube y locales, lo que permite una autenticación segura, una gestión sencilla de los derechos y una conexión única sin problemas para los usuarios finales.

¿Puedo combinar empleados y no empleados en un solo dominio de identidad?

No. OCI IAM los considera poblaciones de usuarios independientes para las licencias. Sin embargo, puedes utilizar el mismo servicio OCI IAM para gestionar dos o más dominios que pueden alojar a empleados y no empleados (socios, filiales, consumidores, etc.). Se pueden utilizar varios dominios para acceder a las mismas aplicaciones, pero las reglas y las políticas de seguridad para no empleados suelen ser diferentes de las que se aplican a los empleados. Cada dominio tiene su propio conjunto de parámetros, configuraciones y políticas de seguridad que son únicas para esa población de usuarios. Esto es por diseño para adaptarse a los requisitos muy variables que son típicos para diferentes poblaciones de usuarios.

¿Quién tiene acceso a un dominio de identidad?

Cada arrendamiento de OCI incluye un grupo de administradores que proporciona acceso completo a todos los recursos de OCI. Es importante comprender que todos los miembros del grupo de administradores de OCI tienen acceso completo para gestionar los dominios de identidad de OCI IAM. Oracle recomienda un uso cuidadoso de este grupo. Los privilegios administrativos se pueden otorgar en cada dominio mediante los roles de administrador, que permiten la separación de tareas entre grupos de personas. Consulta Descripción de los roles de administrador para obtener más información.

¿OCI IAM ofrece una alta disponibilidad o recuperación ante desastres?

En cada región de OCI, hay varios dominios de disponibilidad (availability domains, AD) o dominios de errores (fault domains, FD) (en regiones de un solo AD). Los AD y los FD cumplen funciones similares, pero los FD están físicamente más cerca que los AD. Los dominios de identidad se despliegan con instalaciones redundantes en cada región (dos en los AD/FD) que ofrecen alta disponibilidad. Los dominios de identidad de OCI IAM también ofrecen recuperación ante desastres (disaster recovery, DR) entre regiones mediante un enfoque activo-pasivo que aprovecha la replicación de datos de alto rendimiento. Esto proporciona una recuperación de datos confiable para los dominios de identidad en el caso poco probable de que toda una región de OCI deje de estar disponible. Esta DR se entrega a través de una única URL, por lo que es transparente para las aplicaciones.

¿Cuáles son los términos y conceptos principales de Oracle Identity and Access Management?

Los conceptos principales de IAM son los siguientes:

  • Cuenta o arrendamiento: al registrarte en OCI, Oracle, creas un arrendamiento para tu compañía, que es una partición aislada dentro de OCI donde puedes crear, organizar y administrar tus recursos en la nube. A veces se denomina cuenta de OCI.
  • Compartimento: contenedor lógico dentro de una cuenta de OCI para recursos de Oracle Cloud. Los administradores pueden crear uno o más compartimentos en una cuenta de OCI para organizar y gestionar recursos. Por ejemplo, los compartimentos se pueden utilizar para aplicar la separación de tareas entre diferentes tipos de administradores (red, recursos informáticos, almacenamiento, etc.).
  • Compartimento raíz: compartimento de nivel superior dentro de una cuenta de OCI. El compartimento raíz se crea automáticamente cuando se aprovisiona su cuenta.
  • Dominios de identidad: un dominio de identidad representa una población de usuarios en OCI y configuraciones y parámetros de seguridad asociados. Cada cuenta incluye un dominio de identidad por defecto que permite a los clientes gestionar el acceso a los recursos de OCI. Los clientes pueden elegir crear dominios de identidad adicionales en función de sus necesidades específicas. Los dominios de identidad se crean dentro de un compartimento y el acceso para gestionar dominios está vinculado a los permisos de compartimento. Las políticas de acceso de OCI se pueden escribir para permitir que los usuarios de un compartimento o dominio determinado accedan a los recursos de otros compartimentos.
  • Usuario: una entidad que se puede autenticar. Un usuario puede ser una persona o una cuenta de máquina. Cada usuario tiene un nombre único en su cuenta y un identificador único global. Los usuarios pueden recibir contraseñas para acceder a la consola web y claves para acceder a los servicios a través de las API.
  • Grupo: un conjunto de usuarios. Los grupos se utilizan para simplificar la gestión de los accesos. Por ejemplo, los desarrolladores de software pueden agruparse como miembros de un grupo de “desarrolladores”, lo que les permite leer o modificar códigos. Un único usuario puede ser miembro de varios grupos.
  • Política: documento que especifica quién puede acceder a qué recursos de OCI y qué privilegios tienen. Una política está formada por sentencias de política que aprovechan la sintaxis de lenguaje natural.

¿Qué tiene de especial el enfoque de Oracle Cloud Infrastructure para la gestión de identidades y accesos (IAM)?

Con OCI IAM, puedes aprovechar un único modelo para la autenticación y autorización en todos los servicios de Oracle Cloud y Cloud Application. OCI IAM facilita la gestión de los accesos a organizaciones de todos los tamaños, desde una persona que trabaja en un solo proyecto hasta grandes empresas que tienen muchos grupos que trabajan en diversos proyectos a la vez, todo ello en una misma cuenta. La gestión y autorización de recursos pueden realizarse en el nivel de cuenta o en el nivel de compartimento, al tiempo que se siguen permitiendo la auditoría y facturación centrales. OCI IAM se creó desde el principio para permitirte aplicar el principio de seguridad del privilegio mínimo; por defecto, los nuevos usuarios no pueden realizar ninguna acción en ningún recurso. Los administradores solo pueden otorgar a cada usuario el acceso adecuado para ese usuario específico.

Además de gestionar los recursos de OCI, OCI IAM pone a tu alcance una solución IDaaS de clase empresarial. Con un clic puede desplegar una solución de IAM sólida que se pueda utilizar para abordar muchos requisitos de IAM en casos de uso de empleados/personal, socios o consumidores.

¿Cómo admite Oracle Cloud Infrastructure la autenticación multifactor?

OCI IAM proporciona un amplio soporte para la autenticación multifactor (multi-factor authentication, MFA) que incluye una aplicación MFA móvil que ofrece opciones de push o código de acceso de un solo uso, soporte para autenticadores FIDO2 y soporte para SMS, correo electrónico, llamada telefónica, etc. OCI IAM también incluye seguridad adaptable sensible al contexto que reduce el riesgo sin introducir obstáculos en la experiencia del usuario final. Adaptive Security evalúa el dispositivo, la red, la ubicación y el comportamiento anterior del usuario para crear una puntuación de riesgo para la sesión del usuario. Los administradores pueden configurar políticas de MFA que pueden diferir para aplicaciones específicas o para grupos de usuarios específicos.

¿Los cambios en los usuarios, grupos, compartimentos y políticas se registran con fines de depuración y auditoría?

Sí. Para cumplir con los requisitos empresariales de auditoría y conformidad, todos los cambios se registran y estos registros pueden ponerse a tu disposición sin costo adicional.

¿Cómo empiezo a usar OCI IAM?

OCI IAM está habilitado de forma predeterminada sin cargo adicional. El primer usuario de tu cuenta es el administrador predeterminado. Todos los usuarios posteriores se crean a través del servicio IAM, donde les otorga explícitamente privilegios para interactuar con determinados recursos en la nube.

Puede acceder a Oracle IAM mediante la Consola, la API de REST o los SDK.

Como usuario de Oracle Cloud Infrastructure, ¿cómo restablezco mi contraseña?

Para restablecer su contraseña de Oracle Cloud Infrastructure, primero debe asegurarse de haber asociado una dirección de correo electrónico a su cuenta. Visita la página de perfil de usuario para tu cuenta de Oracle Cloud Infrastructure y añade una dirección de correo electrónico a la que solo tú tengas acceso. Recibirá un correo electrónico para confirmar que realmente quiere registrar esa dirección con su cuenta. Después, puede restablecer la contraseña con su cuenta de correo electrónico a menos que el administrador de su inquilino la haya deshabilitado.

Compartimentos

¿Qué problemas deben resolver los compartimentos diseñados?

Un compartimento es un contenedor lógico seguro dentro de su cuenta que se utiliza para alojar sus recursos de infraestructura (como computación, almacenamiento y red), junto con un conjunto de políticas de gestión de accesos para estos recursos. Los compartimentos le permiten organizar de forma lógica sus recursos en la nube para admitir una amplia variedad de casos de uso.

A continuación se muestran algunos usos comunes de los compartimentos:

  • Separar los entornos de desarrollo de software para simplificar la administración. Por ejemplo, puede tener compartimentos diferentes para desarrollo, pruebas y producción; o bien puede tener compartimentos separados para admitir un despliegue blue/green.
  • Simplificar la gestión de permisos. Por ejemplo, puede crear un compartimento separado para sus recursos de red (VCN, subredes, puertas de enlace de Internet, etc.) y permitir que solo los administradores de red accedan a ese compartimento.
  • Medir por separado el uso que hacen las distintas unidades de negocio a fin de cobrarles adecuadamente su consumo de recursos en la nube.
  • Minimizar el conjunto de recursos visibles para ciertos conjuntos de usuarios. Por ejemplo, quizás desee tener un compartimento separado para su equipo de Finanzas que solo sea visible para ciertos empleados.

¿Los compartimentos pueden contener recursos en varios dominios de disponibilidad?

Sí. Los compartimentos son agrupaciones lógicas de recursos distintas de las construcciones físicas de los dominios de disponibilidad. Un compartimento individual puede contener recursos en varios dominios de disponibilidad.

¿Cómo se usan los compartimentos para el control de accesos?

Todas las políticas se asocian al compartimento raíz o a un compartimento secundario. Cada política consta de una o más declaraciones de política que siguen esta sintaxis básica:

Permite compartimento de grupo

Las declaraciones de las políticas le permiten usar compartimentos para simplificar la gestión de los permisos; por ejemplo, puede escribir una política que permita al grupo AdministradoresRRHH gestionar todos los recursos del compartimento CompartimentoRRHH.

¿Puedo eliminar compartimentos?

Sí, puede eliminar compartimentos.

¿Puedo mover árboles de compartimentos enteros y sus recursos incluidos?

Sí, puede mover árboles de compartimentos enteros y sus recursos incluidos a otros compartimentos principales.

¿Puedo mover recursos, como una instancia de computación o un volumen de bloque, de un compartimento a otro?

Sí, puede mover recursos de un compartimento a otro.

¿Puedo crear una jerarquía de compartimentos?

Sí, puede crear una jerarquía de compartimentos anidándolos. Con los compartimentos jerárquicos o anidados, el administrador del sistema puede organizar los recursos y permitir que los administradores de nivel inferior hagan lo mismo, al tiempo que conserva total visibilidad y control a través de la política.

¿Con cuántos niveles de profundidad se pueden anidar compartimentos?

Un compartimento se puede anidar hasta seis niveles de profundidad como máximo.

¿Las políticas de un compartimento de nivel superior se aplican a un compartimento secundario?

Sí, los compartimentos secundarios heredan las políticas de los compartimentos de nivel superior.

¿Puedo rastrear los costos y el uso por compartimentos?

Sí, puede rastrear los costos y el uso por compartimentos en My Services.

¿Qué es el compartimento raíz?

Para cada cuenta, Oracle Cloud Infrastructure crea automáticamente un compartimento de nivel superior conocido como el compartimento raíz. Al igual que ocurre con la carpeta raíz en un sistema de archivos, el compartimento raíz se comporta exactamente como sus compartimentos secundarios, a excepción de algunas características especiales:

  • Como los permisos son jerárquicos, los permisos de grupo en el compartimento raíz se aplicarán a todos los compartimentos secundarios. Por ejemplo, si se ha otorgado al grupo AdminsRed permiso para gestionar redes virtuales en la nube (VCN) en el compartimento raíz, ese grupo podrá gestionar las VCN en todos los compartimentos.
  • Actualmente, todos los usuarios y grupos se crean dentro del compartimento raíz. Pueden utilizarse políticas para otorgarles acceso solo a determinados compartimentos secundarios.

Nota: Actualmente, solo puedes crear compartimentos adicionales dentro del compartimento raíz, no dentro de otros compartimentos.

¿Cuándo debería crear recursos en el compartimento raíz y cuándo en un compartimento secundario?

En general, los recursos deben crearse en un compartimento que no sea el compartimento raíz. Es mejor que diseñe su jerarquía de compartimentos antes de comenzar a crear compartimentos y recursos.

Usuarios

¿Qué puede hacer un usuario de la consola de Oracle Cloud Infrastructure?

Un usuario es alguien que puede autenticarse con éxito en OCI IAM y que tiene privilegios suficientes para consumir o gestionar recursos en la nube dentro de tu cuenta. Los administradores pueden crear uno o más usuarios dentro de su cuenta y asignarlos a grupos para otorgarles permisos para recursos de compartimentos específicos.

¿Quién puede crear y gestionar usuarios?

Tu cuenta está provista de un solo usuario, el administrador predeterminado, y un solo grupo, los administradores, del cual es miembro el usuario administrador predeterminado. Este grupo (Administradores) tiene acceso total en su cuenta. Este usuario especial (administrador predeterminado) debe crear todos los usuarios adicionales u otorgar permiso a otros usuarios para que puedan crear nuevos usuarios.

¿Qué acceso tiene un usuario nuevo después de su creación?

De manera predeterminada, un usuario nuevo no tiene permiso para usar ningún recurso o servicio dentro de su cuenta; todos los permisos se deben otorgar explícitamente. Este enfoque le permite adherirse al principio de seguridad del privilegio mínimo por el cual solo se otorga a cada usuario el acceso necesario para ese usuario específico. Debe añadir explícitamente a los usuarios a un grupo existente o crear un grupo nuevo para ellos, y después asignar los permisos adecuados a ese grupo a través de una política.

¿Puedo habilitar y deshabilitar el acceso de los usuarios?

Los administradores pueden desactivar o bloquear un usuario para desactivar su acceso temporalmente. También pueden restablecer contraseñas de usuario o eliminar claves.

¿Podemos configurar contraseñas para que caduquen? ¿Cómo puedo rotar las credenciales?

Sí, las políticas de contraseñas te permiten definir un tiempo de caducidad para las contraseñas. También puedes automatizar restablecimientos de contraseña, cambios de clave o ediciones de usuarios y miembros de grupos mediante API de REST y SDK.

Políticas

¿Qué es una política?

Una política es un documento que consta de declaraciones descriptivas que otorgan permisos específicos a grupos de usuarios. Están escritas con una sintaxis tipo SQL fácil de entender. Ejemplos de lo que podrían aplicar las políticas:

  • Los administradores del sistema pueden "finalizar" o "reiniciar" sus instancias de computación Bare Metal.
  • Los administradores de red pueden administrar completamente todos los recursos de infraestructura relacionados con la red.
  • Los administradores de TI pueden crear usuarios y editar pertenencias a grupos.

Una política permite que un grupo trabaje de ciertas maneras con determinados tipos de recursos en un compartimento concreto. Opcionalmente, las políticas pueden contener una cláusula condicional ("where ...") que restringe aún más la declaración de política. Las políticas se adhieren a la siguiente sintaxis:

Permite compartimento de grupo [dónde]

Por ejemplo, esta es una declaración de política que otorga permisos para utilizar instancias de computación:

Permite a los desarrolladores de grupos utilizar instancias en el compartimento ProjectA

  • "group_name" es el nombre del grupo al que se le otorgan permisos.
  • “verbs” hace referencia a las acciones que puedes realizar en los recursos; por ejemplo: inspeccionar, leer, utilizar o gestionar.
  • "resource-type" es el recurso en la nube para el que se otorgan permisos. Los tipos de recursos de ejemplo son: instancias, volúmenes y tablas de rutas.
  • "compartment_name" es el nombre del compartimento en el que se organizan los recursos.
  • "conditions" son especificaciones adicionales que reducen el ámbito de la declaración de política. Por ejemplo: “where request.user.id=target.user.id” o “where target.group_name != Administrators”.

Para obtener más detalles, consulta la sección de OCI IAM de la documentación de Oracle Cloud Infrastructure.

¿Los compartimentos secundario heredan las políticas del compartimento raíz?

Sí. Una política que otorga permisos en el compartimento raíz otorga automáticamente los mismos permisos a todos los compartimentos secundarios. Por ejemplo, la siguiente política otorga permiso a todos los usuarios del grupo "InstanceAdmins" para gestionar instancias en el compartimento raíz, así como en todos los compartimentos secundarios:

Permite al grupo InstanceAdmins gestionar instancias en el arrendamiento

¿Las políticas se pueden limitar a compartimentos específicos?

Sí. Cada política está "asociada" a un compartimento. El lugar al que la asocie controla quién puede modificarla o eliminarla. Si asocia una política al compartimento raíz, cualquier persona que tenga acceso para gestionar políticas en el compartimento raíz puede modificarla o eliminarla. Sin embargo, si asocia la política a un compartimento determinado, cualquier persona que tenga acceso para gestionar políticas en ese compartimento puede modificarla o eliminarla. En la práctica, esto significa que es fácil otorgar a los administradores de compartimento (es decir, un grupo con acceso para "gestionar todos los recursos" en el compartimento) acceso para gestionar las políticas de su propio compartimento, sin darles un acceso más amplio para gestionar políticas que residen en la cuenta.

¿Dónde puedo obtener más información sobre cómo escribir declaraciones de política?

Para obtener más información sobre las políticas y las declaraciones de políticas, consulta "Introducción a las políticas" y "Políticas comunes" en la documentación de Oracle Cloud Infrastructure.

Política de denegación de IAM

Preguntas frecuentes sobre las políticas de denegación de OCI Identity and Access Management

Estas preguntas frecuentes ayudan a los usuarios a entender mejor las políticas de denegación de Oracle Cloud Infrastructure (OCI) Identity and Access Management, que permiten a usuarios autorizados gestionar políticas para bloquear acciones de forma explícita, lo que incrementa la seguridad y simplifica el control de accesos en los arrendamientos de OCI. Para más información, consulta la documentación de OCI Identity and Access Management.

Cómo comenzar a usar la denegación de IAM

¿Cómo puedo activar la función de denegación de IAM en OCI?

La función de denegación de IAM es una función opcional que debe ser activada explícitamente por un administrador de arrendamiento. Este deberá acceder primero a la consola de OCI, después a Policies (Políticas), Actions (Acciones) y por último Policy settings (Configuración de políticas). No puede ser activada por usuarios normales ni autores de políticas. Una vez que se activa, la función se convierte en parte permanente del marco de gestión de identidades y accesos del arrendamiento y no puede desactivarse desde la interfaz de usuario. No obstante, un administrador de arrendamiento con capacidad para escribir políticas de denegación puede controlar de forma efectiva el uso de estas escribiendo una política de denegación en el nivel raíz que impida a todos los usuarios excepto aquellos pertenecientes al grupo de administradores por defecto crear o modificar políticas de denegación. Un ejemplo sería" Deny any-user to manage policies in tenancy where target.policy.type='DENY'"

Una vez que la denegación de IAM está activada:

  • OCI incluye automáticamente una política de denegación por defecto en el compartimento raíz para un uso seguro.
  • Solo el grupo de administradores por defecto y el administrador del arrendamiento que activó la denegación de IAM seguirán contando con permisos para configurar y gestionar las políticas de denegación.
  • El administrador del arrendamiento puede entonces actualizar la política de denegación por defecto para permitir a usuarios autorizados, como grupos de administradores de los compartimentos Banking, Investments y Compliance, escribir políticas de denegación en la consola de OCI.

¿Qué son las sentencias de denegación de OCI Identity and Access Management?

Las sentencias de denegación de OCI Identity and Access Management te permiten escribir políticas de denegación explícitas para bloquear acciones específicas en arrendamientos de OCI. De este modo, complementan a las sentencias de autorización de OCI Identity and Access Management para permitir un control preciso de los accesos. Por ejemplo, puedes usar "Deny any-user to inspect all-resources in tenancy where request.service='streaming'" con el fin de establecer una protección que bloquee todo acceso al servicio OCI Streaming en tu arrendamiento, al tiempo que otorgas otros permisos por medio de sentencias de autorización.

¿Cuáles son los límites de las políticas de denegación de IAM?

Las políticas de denegación de IAM están sujetas a los mismos límites que las políticas de admisión. Un arrendamiento puede tener hasta 100 objetos de políticas de gestión de identidades y accesos, cada uno con 50 declaraciones de políticas (de denegación o autorización), pero el número total de declaraciones de políticas en el conjunto de objetos del arrendamiento no puede superar las 100.

¿Qué metaverbos admiten las políticas de denegación de IAM? ¿Son nuevos o ya existen?

Las políticas de denegación de IAM usan los siguientes metaverbos ya existentes: "manage" (gestionar), "use" (usar), "read" (leer) e "inspect" (inspeccionar). No se han introducido nuevos metaverbos. A diferencia de las sentencias de autorización, que otorgan permisos de forma aditiva (por ejemplo, "manage" (gestionar) incluye todos los permisos inferiores), las sentencias de denegación son sustractivas y solo bloquean el permiso especificado y cualquier nivel superior de la jerarquía.

Así, la política "Deny group DevOps to manage instance in compartment Prod" bloquea únicamente el permiso de gestión, permitiendo a DevOps las acciones de uso, lectura e inspección. Sin embargo, la denegación de inspección bloquea todos los permisos, ya que es el permiso de nivel básico.

Creación y gestión de políticas

¿Dónde puedo escribir políticas de denegación en la consola de OCI?

Las políticas de denegación se crean en la misma interfaz de la consola de OCI que las políticas de autorización. Ve a Identity & Security (Identidad y seguridad) y, a continuación, a Policies (Políticas), selecciona un compartimento y usa el editor de políticas para agregar la palabra clave "deny" (denegar) junto a "allow" (permitir). Este proceso no requiere una interfaz independiente.

¿Existe un objeto de política independiente para las políticas de denegación?

No, las políticas de denegación usan el mismo objeto de política que las políticas de admisión. Ambas se gestionan mediante el mismo objeto de política para una administración más sencilla.

¿Puedo incluir sentencias de autorización y denegación en un mismo objeto de política de gestión de identidades y accesos?

Sí, puedes combinar sentencias de autorización y denegación en un objeto de política para un control de accesos flexible.

Una política puede incluir sentencias de autorización y denegación, como te mostramos en el siguiente ejemplo:

Deny group Interns to use instance in compartment Finance
Allow group Admins to manage all-resources in compartment Finance

Estas políticas permiten a los administradores gestionar todos los recursos del compartimento Finance, mientras que impiden a los usuarios del grupo Interns realizar cualquier operación de escritura en las instancias, optimizando el control de accesos.

¿Cómo puedo impedir que los usuarios que gestionan políticas escriban políticas de denegación?

Para evitar que los usuarios de políticas autorizados a gestionar políticas escriban políticas de denegación, crea una política de denegación en el nivel raíz para bloquear la creación de políticas de denegación.

Ejemplo: Deny group PolicyAdmins to manage policies in tenancy where target.policy.type='DENY'

Esta política garantiza que los administradores de políticas no puedan crear ni modificar políticas de denegación, al tiempo que les sigue permitiendo gestionar políticas de autorización. Los grupos de administradores por defecto no están sujetos a esta política y pueden escribir políticas de denegación en caso necesario.

¿Cómo puedo bloquear un servicio de OCI completo mediante una política de denegación de IAM?

Para bloquear un servicio de OCI completo, crea una política de denegación en el compartimento raíz que se aplique a los recursos o acciones del servicio por medio de una condición como request.service.name.

Por ejemplo, para bloquear el servicio OCI Streaming en todo el arrendamiento

Deny any-user to inspect all-resources in tenancy where request.service.name='streaming'

Esta política impide todo acceso al servicio OCI Streaming, lo que facilita el cumplimiento normativo en industrias como el sector salud. Ubica la política en el compartimento raíz para garantizar que se aplique a todos los compartimentos y reducir así la proliferación de políticas.

¿Cómo puedo impedir a un grupo gestionar recursos en una región específica?

Para impedir a un grupo gestionar recursos en una región específica, utiliza una política de denegación con request.region condition.

Por ejemplo, si quieres impedir a un grupo realizar cualquier acción más allá del acceso de solo lectura en una región específica, puedes escribir una política de denegación como la siguiente:

Deny group RegionalAdmins to use all-resources in tenancy where request.region='sa-saopaulo-1'

Esta política impide al grupo RegionalAdmins usar recursos de la región de São Paulo, pero les otorga permisos de uso, lectura e inspección. Es ideal para instituciones financieras con obligaciones de cumplimiento normativo ligadas a leyes regionales de residencia de datos.

¿Cómo puedo impedir a un grupo acceder a las instancias informáticas de un compartimento específico?

Para impedir que un grupo acceda a las instancias informáticas de un compartimento específico, usa

Deny group DevTeam to inspect instance in compartment ProjectX

Esta política bloquea todos los permisos (inspección, lectura, uso, gestión) en las instancias informáticas del compartimento ProjectX. Por ejemplo, una empresa tecnológica puede usarla para impedir que el grupo DevTeam acceda a las instancias de producción, aislando los entornos de desarrollo y producción para incrementar la seguridad.

¿Cómo puedo impedir a un grupo gestionar el almacenamiento de objetos de un compartimento específico?

Para impedir que un grupo gestione los recursos de almacenamiento de objetos de un compartimento específico, usa

Deny group StorageUsers to inspect object-family in compartment DataLake

Esta política bloquea todos los permisos (inspección, lectura, uso, gestión) en los recursos de almacenamiento de objetos del compartimento DataLake. Una organización del sector salud podría aplicarla, por ejemplo, para evitar que el grupo StorageUsers acceda a datos sensibles de los pacientes a fin de garantizar el cumplimiento de las normas de privacidad.

¿Cómo puedo delegar tareas a usuarios autorizados a gestionar políticas en un compartimento secundario sin permitirles modificar ciertos recursos o escribir políticas de denegación?

Para delegar tareas de forma segura a usuarios autorizados a gestionar políticas en un compartimento secundario, puedes

  • Otorgar permisos específicos para ciertos compartimentos o recursos mediante políticas de autorización.
  • Restringir la autoría de políticas de denegación para impedir que usuarios autorizados a gestionar políticas en un compartimento secundario creen políticas disruptivas.
  • Utilizar políticas de denegación para bloquear el acceso a recursos sensibles.

Por ejemplo, para permitir a usuarios autorizados a gestionar políticas en un compartimento secundario gestionar recursos informáticos en un compartimento restringiendo los cambios de red y denegando la creación de políticas, usa las políticas siguientes:

Deny group ProjectAdmins to manage network-family in compartment ProjectX Deny group ProjectAdmins to manage policies in compartment ProjectXwhere target.policy.type='DENY'

Allow group ProjectAdmins to manage instance-family in compartment ProjectX

Estas políticas permiten a los usuarios del grupo ProjectAdmins gestionar instancias en ProjectX y les impiden modificar redes y escribir políticas de denegación, facilitando una delegación segura. Una organización financiera podría usar este enfoque para permitir a subadministradores gestionar recursos informáticos manteniendo un control estricto de las configuraciones de red y la gestión de políticas.

Mecanismos de seguridad y recuperación

¿Se evalúan las políticas de denegación antes que las de autorización?

Sí, OCI Identity and Access Management aplica un modelo de evaluación de denegación en primer lugar, según el cual las políticas de denegación se evalúan antes que las de autorización en la jerarquía de compartimentos. Cuando una solicitud coincide con una política de denegación se bloquea el acceso, independientemente de las políticas de autorización. Los grupos de administradores por defecto están exentos de las políticas de denegación para evitar bloqueos.

Por ejemplo, en el compartimento Prod podrían existir las siguientes políticas:

Deny group Devs to manage instance-family in compartment Prod
Allow group Devs to manage all-resources in compartment Prod

La política de denegación impide al grupo Devs gestionar instancias, mientras que los administradores por defecto siguen pudiendo gestionar instancias.

¿Qué sucede si un usuario autorizado a gestionar políticas escribe una política de denegación que bloquea el acceso a todos los usuarios del arrendamiento?

El grupo de administradores por defecto está exento de las políticas de denegación, por lo que sus miembros pueden iniciar sesión, ver y editar las políticas para resolver cualquier bloqueo. Esta protección ayuda a evitar interrupciones en los arrendamientos.

Ejemplo: si se aplica "Deny any-user to inspect all-resources in tenancy", los usuarios del grupo de administradores por defecto siguen pudiendo iniciar sesión y acceder al editor de políticas para eliminar esta política o modificarla.

¿Cómo me recupero si una política de denegación aplicable a todo el arrendamiento bloquea a todos los usuarios?

Una política de denegación aplicable a todo el arrendamiento, como "Deny any-user to inspect all-resources in tenancy", puede impedir el acceso a todos los usuarios, causando una interrupción. Para solucionarlo:

1. Inicia sesión como miembro del grupo de administradores por defecto (exento de las políticas de denegación).
2. En la consola de OCI, ve a Identity & Security (Identidad y seguridad) y a continuación a Policies (Políticas).
3. Localiza la política problemática en el compartimento raíz.
4. Edita o suprime la política (por ejemplo, cambia "Deny any-user to inspect all-resources in tenancy" por "Deny group Interns to inspect all-resources in tenancy").
5. También puedes usar la siguiente interfaz de línea de comandos de OCI: oci iam policy update --policy-id --statements '["Deny group Interns to inspect all-resources in tenancy"]

Por ejemplo, si un usuario autorizado a gestionar políticas en un compartimento secundario aplica por accidente "Deny any-user to inspect all-resources in tenancy", un usuario del grupo de administradores por defecto puede iniciar sesión y modificarla para que solo afecte al grupo Guests, lo que impedirá bloqueos en el futuro. Para evitar este tipo de problemas, prueba las políticas de forma exhaustiva y limita la autoría de las políticas de denegación.

Efectos en los permisos

¿Qué sucede si deniego el permiso de gestión?

Denegar el permiso de gestión solo bloquea esta acción. La capacidad de usar, leer e inspeccionar quedan intactas.

Ejemplo: "Deny group DevOps to manage instance in compartment Production" impide a los usuarios del grupo DevOps gestionar instancias, pero les permite usarlas, leerlas o inspeccionarlas.

¿Qué sucede si deniego el permiso de uso?

Denegar el uso bloquea los permisos de uso y gestión, pero se sigue pudiendo leer e inspeccionar.

Ejemplo: "Deny group Testers to use bucket in compartment QA" impide al grupo Testers usar o gestionar buckets, pero les permite leerlos o inspeccionarlos.

¿Qué sucede si deniego el permiso de lectura?

Denegar la lectura bloquea los permisos de lectura, uso y gestión, pero se sigue pudiendo inspeccionar.

Ejemplo: "Deny group Auditors to read logs in compartment Logging" impide a los usuarios del grupo Auditors leer, usar o gestionar logs, pero les permite inspeccionarlos.

¿Qué sucede si deniego el permiso de inspección?

Denegar la inspección bloquea todos los permisos (inspección, lectura, uso, gestión), ya que la inspección es el permiso de nivel más básico.

Ejemplo: "Deny group Viewers to inspect instance in compartment Public" impide por completo el acceso de los usuarios del grupo Viewers a las instancias.

Casos de uso avanzados y solución de problemas

¿Cómo puedo monitorear las políticas de denegación para asegurarme de que funcionan según lo previsto?

Revisa los logs de auditoría de OCI para realizar el seguimiento de las acciones bloqueadas por las políticas de denegación. Si una política como "Deny any-user to inspect cloud-shell in tenancy" causa problemas, refínala a "Deny group Interns to inspect cloud-shell in tenancy". Sé proactivo estableciendo alertas que te adviertan de cambios en las políticas.

Ejemplo: supervisa los logs para ajustar "Deny group Drivers to manage instance-family in compartment Fleet" si bloquea tareas legítimas.

¿Qué errores comunes deben evitarse con las políticas de denegación?

El modelo de denegación primero de OCI prioriza las políticas de denegación con respecto a las de autorización, lo que puede causar problemas si las políticas son demasiado amplias. Entre los errores comunes se incluyen: aplicar bloqueos a todo el arrendamiento o a compartimentos completos o usar condiciones demasiado amplias basadas en etiquetas.

Por ejemplo, una política como "Deny any-user to inspect all-resources in tenancy" puede impedir el acceso a todos los usuarios, causando un bloqueo en todo el arrendamiento. En su lugar, usa políticas específicas, como las siguientes:

Deny group Interns to inspect all-resources in compartment Public

Esta política restringe el acceso al grupo Interns únicamente, evitando interrupciones no deseadas. Una compañía tecnológica podría aplicar este enfoque para limitar el acceso de usuarios invitados, preservando al mismo tiempo la funcionalidad para los demás usuarios. Para evitar problemas, experimenta con las políticas en un entorno de prueba, asegúrate de que sean sencillas y restringe la autoría de políticas de denegación.

¿Pueden usarse sentencias de denegación para casos de uso que abarcan varios arrendamientos?

Sí, pueden usarse sentencias de denegación en escenarios que incluyen varios arrendamientos. Una sola sentencia "deny endorse" o "deny admit" puede bloquear solicitudes entre arrendamientos, a diferencia de los pares "endorse/admit", que requieren que ambas condiciones se satisfagan.

El siguiente arrendamiento de origen es un ejemplo:

Endorse group Devs to use object-family in tenancy PartnerTenancy Deny endorse group Devs to manage object-family in tenancy PartnerTenancy

Esto permite a los usuarios del grupo Devs utilizar el almacenamiento de objetos del arrendamiento Partner Tenancy, pero bloquea las acciones de gestión. Una organización asociada puede usar esto para permitir el intercambio de datos manteniendo el control de los recursos.

¿Cómo interactúan las políticas con OCI Zero Trust Packet Routing?

OCI Zero Trust Packet Routing opera en la capa 4 (nivel de red) del modelo de interconexión de sistemas abiertos, mientras que las políticas de denegación de IAM controlan los accesos en la capa 7 (nivel de aplicación). Aunque OCI Zero Trust Packet Routing permita la comunicación, las políticas de denegación de IAM todavía podrían bloquear acciones.

Ejemplo:

  • Política de OCI Zero Trust Packet Routing: "Allow dynamic-group FrontEnd in VCN web:vcn to connect to backend:server-instance in VCN vcn:server permits network traffic".
  • Política de IAM: "Deny dynamic-group FrontEnd to manage instance-family in compartment ProjectA blocks instance management despite OCI Zero Trust Packet Routing allowance".

Las políticas de OCI Zero Trust Packet Routing e IAM se evalúan de forma secuencial, siendo IAM el criterio final.

¿Cómo interactúan las políticas definidas por el sistema con la políticas de denegación?

Las políticas estándar del sistema siempre prevalecen sobre las políticas de denegación definidas por los usuarios para garantizar el funcionamiento de los servicios esenciales (por ejemplo, "Allow any-user to read domains in tenancy where target.domain.id='request.domain.id'").

Ejemplo: una política de denegación como "Deny group Users to read domains in tenancy" no bloqueará una política estándar del sistema que permita el acceso a los dominios.

¿Se evalúan las políticas de denegación de forma distinta que las de autorización?

OCI Identity and Access Management aplica un modelo de evaluación de denegación en primer lugar, según el cual las políticas de denegación se evalúan antes que las de autorización en la jerarquía de compartimentos. Cuando una solicitud coincide con una política de denegación se bloquea el acceso, independientemente de las políticas de autorización. Las políticas definidas por el sistema pueden anteponerse a las denegaciones definidas por el usuario (ver la pregunta 27). Los grupos de administradores por defecto están exentos de las políticas de denegación, por lo que pueden gestionar políticas durante un bloqueo.

Ejemplo: si "Deny group Users to manage instance-family in compartment Prod" coexiste con "Allow group Users to manage all-resources in compartment Prod", la política de denegación bloquea la gestión de instancias.

¿Se antepone la denegación de IAM a los roles de administración de dominio de identidad (por ejemplo, administrador de dominio de identidad, administrador de seguridad y gestor de usuarios)?

En la versión actual, las políticas de denegación de IAM no se anteponen a los roles de administración de Oracle Identity Cloud Service (por ejemplo, administrador de dominio de identidad, administrador de seguridad y gestor de usuarios). Esta es una limitación. En la próxima versión, la denegación de IAM tendrá prioridad sobre los roles de administración de Oracle Identity Cloud Service para un control de accesos consistente.

¿Cómo puedo usar la denegación de IAM de forma que el acceso a un servicio solo se realice a través del nuevo OCI Private Service Access?

OCI Private Service Access permite acceder a los servicios de Oracle a través de una ruta de red privada en lugar de la red pública de internet. OCI Private Service Access se ha diseñado para los clientes que quieren disfrutar de conectividad privada entre sus cargas de trabajo y los servicios de Oracle, ya sea por motivos de cumplimiento normativo, rendimiento o seguridad.

Si utilizas OCI Private Service Access para acceder de forma segura a un servicio (como OCI Object Storage u OCI Streaming), te recomendamos que establezcas que todos los accesos se realicen a través de OCI Private Service Access. Con la denegación de IAM, puedes bloquear de forma explícita todo el tráfico que no provenga de OCI Private Service Access a un servicio, aunque existan políticas de autorización.

Por ejemplo, para permitir el acceso a OCI Object Storage únicamente a través de OCI Private Service Access, usa

Deny any-user to access object-family in tenancy where any {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

Está política impide a los usuarios acceder a OCI Object Storage a menos que su tráfico se enrute a través de un punto final de OCI Private Service Access. Es especialmente útil si has establecido una configuración de OCI Private Service Access para datos confidenciales y quieres eliminar cualquier riesgo de acceso a través de rutas públicas no deseadas.

¿Cuál es la diferencia entre las políticas de denegación de OCI Identity and Access Management y Oracle Security Zones, y cuándo debería usar cada una?

OCI ofrece políticas de denegación de IAM y Oracle Security Zones te permite garantizar la seguridad de tu arrendamiento impidiendo acciones no seguras. Aunque las dos soluciones fortalecen tu seguridad, son distintas en su funcionamiento y su grado de flexibilidad.

  • Similitudes: tanto las políticas de denegación de IAM como Oracle Security Zones bloquean acciones específicas para proteger tus recursos y garantizar la aplicación de buenas prácticas de seguridad en tu arrendamiento de OCI.
  • Diferencias principales
    • Políticas de denegación de IAM: las políticas personalizadas que creas bloquean acciones en función de ciertas condiciones, como la identidad de los usuarios, el tipo de recursos, la dirección IP, o de etiquetas. Estás políticas actúan como barreras de seguridad y a partir de la próxima versión se antepondrán a todas las políticas de IAM. Por ejemplo, puedes impedir a un grupo de usuarios dado suprimir recursos críticos si el recurso tiene una etiqueta específica, como environment:production.
    • Oracle Security Zones: aplica reglas de seguridad predefinidas a compartimentos específicos o a todo el arrendamiento. Cuando se activa, Oracle Security Zones aplica automáticamente restricciones a un conjunto de servicios de OCI, como bloquear subredes públicas o desactivar el cifrado. No necesitas escribir políticas, las reglas vienen incorporadas y comprueban automáticamente la configuración de los recursos.
  • Cuándo utilizar cada solución
    • Utiliza las políticas de denegación de IAM, para restricciones personalizadas y específicas, como bloquear ciertos usuarios o acciones en función de las condiciones que definas.
    • Usa Oracle Security Zones para conseguir reglas de seguridad automáticas y listas para usar que te permiten aplicar buenas prácticas con una configuración mínima.
    • Combina ambas soluciones para lograr una protección más robusta. Activa Oracle Security Zones para disponer de barreras de seguridad básicas amplias. Añade políticas de denegación de IAM para conseguir controles específicos hechos a medida.

¿Necesitas ayuda con las políticas de denegación de OCI Identity and Access Management?

Para obtener más ayuda, consulta la documentación de OCI Identity and Access Management o ponte en contacto con tu equipo de cuenta de OCI.

Grupos

¿Qué es un grupo?

Un grupo es una colección de usuarios que necesitan privilegios de acceso similares para poder usar o gestionar un recurso específico dentro de su cuenta. Los usuarios pueden formar parte de varios grupos. Los permisos son aditivos. Por ejemplo, si la pertenencia a un grupo permite a un usuario utilizar instancias de computación, y la pertenencia a un segundo grupo permite a ese usuario gestionar volúmenes de bloque, el usuario puede gestionar tanto instancias como volúmenes de bloque.

Los administradores escriben políticas que especifican el acceso que los grupos (no usuarios individuales) necesitan, ya sea para un compartimento específico o para la cuenta. Después, los administradores añaden usuarios a los grupos correspondientes.

¿Puedo tener varios administradores?

Sí. Su cuenta está aprovisionada con un único administrador predeterminado que pertenece a un grupo Administradores dentro de su compartimento raíz. Este grupo tiene todos los privilegios para crear y gestionar todos los recursos de Oracle Cloud Infrastructure en su cuenta, incluidos usuarios, grupos, políticas y compartimentos, así como todos los demás recursos de infraestructura en la nube dentro de cualquier compartimento. Puede añadir usuarios adicionales a este grupo Administradores.

Funciones

¿Cómo aborda OCI IAM los requisitos de caducidad de las contraseñas?

Las políticas de contraseñas te permiten definir un tiempo de caducidad para las contraseñas. Una política de contraseñas por defecto define las contraseñas para que caduquen después de los 120 días. Esto se puede configurar y se pueden aplicar diferentes políticas a subgrupos de usuarios.

¿Cómo puedo ejecutar tareas en una instancia informática sin embeber credenciales de usuario en ellas?

Utiliza grupos de recursos dinámicos para asignar un conjunto de recursos informáticos a un grupo. Puedes asignar los permisos de grupo mediante una política. Esto permite que una instancia informática acceda a otros recursos de OCI de forma segura sin embeber credenciales en secuencias de comandos.

Federación

¿Qué es la federación de identidades en Oracle Cloud Infrastructure?

La federación de identidades es un mecanismo para delegar la gestión de usuarios de su inquilino de Oracle Cloud Infrastructure a otra entidad denominada proveedor de identidades o IdP. Resulta muy útil para las empresas que ya tienen un sistema de identidad y que les gustaría usarlo, en lugar de crear y mantener un nuevo conjunto de usuarios. La federación requiere una configuración que se realiza una sola vez entre Oracle Cloud Infrastructure y el IdP conocida como confianza de federación.

¿Qué son los usuarios federados?

Los usuarios federados (identidades externas) son usuarios que gestionas fuera de Oracle Cloud Infrastructure (por ejemplo, en tu directorio corporativo), pero a quienes otorgas acceso a tu cuenta de Oracle Cloud Infrastructure. Son distintos de los usuarios de Oracle Cloud Infrastructure, que se crean y mantienen en su cuenta de Oracle Cloud Infrastructure.

¿Los usuarios federados pueden acceder a la consola de Oracle Cloud Infrastructure?

Sí. Los usuarios federados pueden acceder a la consola de Oracle Cloud Infrastructure.

¿Los usuarios federados pueden acceder al SDK y la CLI de Oracle Cloud Infrastructure?

Sí. Los usuarios federados pueden acceder al SDK y la CLI de Oracle Cloud Infrastructure.

¿Qué acciones pueden realizar los usuarios de Oracle Cloud Infrastructure en la consola que los usuarios federados no pueden llevar a cabo?

Los usuarios federados no pueden cambiar ni restablecer sus contraseñas en la consola de Oracle Cloud Infrastructure.

¿Cómo se controla lo que un usuario federado puede hacer cuando inicia sesión en la consola?

Utilice las mismas políticas de Oracle Cloud Infrastructure para gestionar usuarios federados que las que usa para gestionar usuarios nativos. Puede asignar roles y grupos en su proveedor de identidades a grupos en Oracle Cloud Infrastructure. Cuando un usuario federado inicia sesión, la consola de Oracle Cloud Infrastructure aplica políticas en función de su pertenencia a grupos de Oracle Cloud Infrastructure, igual que ocurre con los usuarios nativos. Consulte la documentación para ver ejemplos.

Solo se puede asignar un rol o grupo en su proveedor de identidades a varios grupos de Oracle Cloud Infrastructure. Además, se pueden asignar varios roles o grupos en su proveedor de identidades a un solo grupo de Oracle Cloud Infrastructure.

¿A cuántos usuarios federados puedo otorgar acceso a la consola de Oracle Cloud Infrastructure?

No hay ningún límite en cuanto al número de usuarios federados a los que se les puede otorgar acceso a la consola.

¿Con qué proveedores de identidades se ofrece compatibilidad?

OCI IAM soporta cualquier proveedor de identidad compatible con SAML 2.0, Open ID Connect o OAuth, incluidas soluciones populares como Oracle Access Manager, Microsoft Active Directory Federation Services (AD FS) y Okta.

Autenticación multifactor

¿Qué es la autenticación multifactor (MFA) y por qué es importante?

Históricamente, las cuentas estaban protegidas simplemente con un nombre de usuario y contraseña. Pero las contraseñas pueden ser difíciles de recordar y relativamente fáciles de capturar con técnicas de ciberataque comunes, como análisis de tráfico, el phishing y los ataques de fuerza bruta. Si alguien roba tus credenciales, pueden hacerse pasar por ti y acceder a todas tus cuentas y recursos.

La MFA es una característica de seguridad popular que ayuda a reducir el riesgo de usurpación al fortalecer la garantía de que el usuario de la aplicación es quien afirma ser. La MFA exige que los usuarios proporcionen más de un factor de autenticación. Hay tres categorías de factores de autenticación: algo que sabes (como una contraseña o un PIN), algo que tienes (como un token de seguridad o un teléfono móvil) y algo que eres (como datos biométricos como una huella o un escaneo facial). Con la MFA activada, incluso si un atacante logra obtener tu contraseña, no podrá autenticarse como tú sin proporcionar la evidencia adicional que solicita la MFA. Esto puede ayudar a evitar el acceso no autorizado y a evitar que la información confidencial se vea comprometida o que se realicen acciones inadecuadas. La activación de la MFA también ayuda a cumplir con los requisitos de cumplimiento normativo y el cumplimiento de los estándares del sector, como los proporcionados por el Instituto Nacional de Estándares y Tecnología (NIST, National Institute of Standards and Technology).

¿Quién debería usar la MFA?

Oracle recomienda habilitar la MFA para todos los usuarios. Como mínimo, se recomienda habilitar la MFA para los usuarios con privilegios administrativos, como la capacidad de crear y administrar recursos de OCI. Deberías también exigir la MFA para acceder a cualquier aplicación que almacene información sensible o permita realizar acciones de alto riesgo.

¿Cuál es la experiencia del usuario final cuando los administradores habilitan la MFA?

Cuando un administrador activa la MFA por primera vez, se le pedirá a los usuarios que se inscriban en la MFA durante su siguiente inicio de sesión. Después de la inscripción inicial, a los usuarios se les pedirá completar la MFA durante el proceso de inicio de sesión en cada visita posterior. Si el administrador habilita el uso de dispositivos de confianza, los usuarios tendrán la opción de seleccionar "confiar en este dispositivo", lo que elimina el requisito de la MFA si el usuario vuelve al mismo dispositivo.

Para obtener más información, los usuarios pueden consultar la siguiente guía:

¿Es obligatorio el uso de la MFA en todas las circunstancias?

No. La MFA no es estrictamente obligatoria en todas las circunstancias. Si estás otorgando acceso a un sitio web público, por ejemplo, normalmente no requerirías ninguna autenticación. Si quieres que los usuarios inicien sesión al realizar una compra para saber en qué cuenta cargar y dónde entregar los productos, quizás un nombre de usuario y una contraseña sean suficientes. Pero si ese mismo usuario desea cambiar el método de pago o la dirección de entrega, o si la aplicación permite acciones que podrían afectar a su organización, entonces se recomienda utilizar la MFA.

Oracle recomienda encarecidamente que actives la MFA para todos los administradores de la nube y las aplicaciones. En última instancia, deberías evaluar si hacer obligatorio el MFA en función de las políticas internas de seguridad de tu organización y la evaluación de riesgos. Sin embargo, es una buena práctica comenzar con una política en la que el uso de la MFA sea siempre obligatorio y requerir la aprobación ejecutiva para cualquier aplicación para la que se desee hacer opcional su uso.

¿Qué factores de la MFA están disponibles para mí? ¿Hay un costo?

Para comprender completamente los factores disponibles y su costo, es importante primero entender qué tipo de arrendamiento de OCI tienes. Para determinar si tu arrendamiento tiene OCI Identity and Access Management (IAM) con dominios de identidad o si tiene OCI IAM sin dominios de identidad, consulta esta documentación.

  • Si tu arrendamiento tiene OCI IAM con dominios de identidad, todos los tipos de dominio de identidad admiten la MFA sin costo adicional. Los dominios de identidad de tipo Libre no pueden utilizar mensajes de texto como factor de autenticación, pero hay otros factores disponibles. Para obtener más información, consulta la documentación de MFA de OCI IAM con dominios de identidad.
  • Si tu arrendamiento tiene OCI IAM sin dominios de identidad, tienes dos opciones para MFA:
    • Habilita MFA para el inicio de sesión directo de los usuarios a través del servicio OCI IAM. Esta opción ofrece un conjunto limitado de factores de autenticación sin costo adicional. Para obtener más información, consulta la documentación de MFA de OCI IAM con dominios de identidad.
    • Aprovecha Oracle Identity Cloud Service (IDCS) para autenticar usuarios en OCI. Esta opción ofrece más funciones de MFA y opciones de autenticación.
  • Si utilizas IDCS para autenticarse, hay dos tipos de licencia:
    • IDCS Foundation (nivel gratuito) solo admite MFA para acceder a la consola de OCI, sin costo, con un conjunto limitado de factores de autenticación, tal como se describe en la documentación disponible aquí. Para proteger otras aplicaciones, tendrías que actualizar a IDCS Standard.
    • IDCS Standard admite una amplia gama de opciones de MFA para cualquier servicio o aplicación protegida sin costo adicional. Para obtener más información, consulta la documentación de MFA de Identity Cloud Service (IDCS).

¿Dónde puedo aprender más sobre cómo implementar la MFA?

Las instrucciones específicas para implementar la MFA varían según el tipo de arrendamiento de OCI que tengas. Para determinar si tu arrendamiento tiene OCI IAM con dominios de identidad o sin dominios de identidad, consulta esta documentación.

¿Qué sucede si no implemento la MFA?

Si no implementas MFA, tendrás un mayor riesgo de que un ataque de toma de control de cuenta dirigida tenga éxito. Sin embargo, con la MFA, tu arrendamiento y otros procesos de autenticación seguirán funcionando normalmente.