Gerenciar Identidades e Políticas de Autorização

O Oracle Cloud Infrastructure Identity and Access Management permite controlar quem tem acesso aos recursos da nuvem. As credenciais para acesso e autorização incluem chaves de API, senha de acesso, acesso federado e tokens de autenticação. Use as credenciais apropriadas para proteger sua conta e recursos da nuvem. A Oracle incentiva você a adotar as seguintes recomendações ao implementar o gerenciamento de identidades na nuvem.

Usar Autenticação Vários Fatores (MFA)

Arquiteto Enterprise, Arquiteto de Segurança, Arquiteto de Aplicativos

Restrinja o acesso aos recursos apenas aos usuários que foram autenticados por meio da solução de sign-on único da sua empresa e uma senha única limitada por tempo ou outro fator adequado, como uma função de varredura biométrica.

Com os domínios de identidade do OCI Identity and Access Management (IAM), a MFA é configurada e aplicada em uma política de sign-on predefinida para a Console do OCI. Esta política não deve ser desativada.

Você deve exigir isso no nível do usuário e aplicá-lo no nível dos recursos por meio do IAM. Você pode impor a MFA para um recurso na política de acesso que permite o acesso ao recurso.

A MFA também pode ser configurada para casos de uso de emergência quando você precisa conceder a um usuário acesso elevado temporário para ignorar o controle de acesso regular para obter acesso imediato a sistemas críticos.

Não Use a Conta de Administrador da Tenancy para Operações do Dia a Dia

Arquiteto Enterprise, Arquiteto de Segurança, Arquiteto de Aplicativos

Os administradores de nível de serviço na tenancy devem ser criados para limitar ainda mais o acesso administrativo. Os administradores em nível de serviço só devem gerenciar recursos de um serviço ou domínio específico.

Por exemplo, a política a seguir permite que os usuários do grupo VolumeAdmins gerenciem apenas os recursos da família de volumes em blocos.

Allow group VolumeAdmins to manage volume-family in tenancy

Criar Políticas de Segurança para Evitar o Bloqueio da Conta do Administrador

Arquiteto Empresarial, Arquiteto de Segurança

Crie e proteja uma conta de administrador especificamente para uso caso o administrador da tenancy saia da sua organização ou para alguma outra emergência quando nenhum administrador da tenancy estiver disponível.

Por exemplo, crie uma persona de Usuário de Emergência, com associação ao grupo Administradores do OCI, não federada e apenas com senha local. Isso às vezes é chamado de conta "Break Glass".

Break Glass refere-se aos processos e mecanismos usados para obter acesso altamente privilegiado em caso de emergência de TI. O termo é derivado da prática de colocar um gatilho de alarme atrás de um painel de vidro protetor, que serve como uma barreira física para evitar a ativação não autorizada ou não emergencial. Em TI, o quebra-cabeça é usado metaforicamente para descrever a necessidade de privilégios de acesso total durante uma emergência crítica que não pode ser abordada dentro da segregação de funções (SOD) estabelecida e controles de acesso menos privilegiados. Os principais recursos de um processo eficaz de emergência são alta disponibilidade, acesso restrito, avaliação de riscos, aprovação rápida, direitos de curta duração, auditoria e testes regulares. Mesmo um modelo de acesso bem projetado pode não ser responsável por todas as emergências possíveis. Nesses casos, o quebra-vidro fornece uma maneira de concentrar o mais alto nível de privilégios de acesso em uma ou mais contas de quebra-vidro, transcendendo o modelo de acesso estabelecido. O Grupo de Administradores do OCI pode ser usado para conceder acesso de emergência, juntamente com uma opção de direito alternativa.

Restringir Grupos de Administradores do IAM do Gerenciamento de Administradores Padrão e Grupos de Administradores de Credenciais

Arquiteto Empresarial, Arquiteto de Segurança

As permissões do administrador devem seguir a regra de privilégio mínimo, portanto, a associação a um grupo Admin ou anexo a uma política Admin deve ser limitada a uma base conforme necessário.

A política a seguir permite que os usuários do grupo UserAdmins inspecionem apenas os grupos na tenancy.

Allow group UserAdmins to inspect groups in tenancy

A Política de Administração de Tenancy pronta para uso também não deve ser alterada.

Impedir a exclusão acidental ou maliciosa de (e alterações nas políticas de acesso)

Arquiteto Enterprise, Arquiteto de Segurança, Arquiteto de Aplicativos

Por exemplo, a política a seguir só permite que os usuários do grupo PolicyAdmins criem políticas, mas não as editem ou excluam.

Allow group PolicyAdmins to manage policies in tenancy where
      request.permission='POLICY_CREATE'

Restrinja os administradores de credenciais para gerenciar somente recursos do usuário e credenciais do usuário, como chaves de API, tokens de autenticação e chaves secretas.

Usar Vários Domínios de Identidade

Arquiteto Empresarial, Arquiteto de Segurança

Use o domínio de identidades padrão do OCI Identity and Access Management somente para Administradores do OCI.

Para cargas de trabalho de aplicativos, use domínios de identidade separados para cada ambiente, como desenvolvimento, teste e produção.
Cada domínio pode ter diferentes requisitos de identidade e segurança para proteger seus aplicativos e serviços do OCI.
O uso de vários domínios de identidade pode ajudar a manter o isolamento do controle administrativo sobre cada domínio de identidades. Vários domínios de identidade são necessários, por exemplo, quando seus padrões de segurança impedem que IDs de usuário sejam desenvolvidos no ambiente de produção. Vários domínios também são usados quando você exige que administradores diferentes tenham controle sobre vários ambientes.

Federar o Oracle Cloud Infrastructure Identity and Access Management

Arquiteto Enterprise, Arquiteto de Segurança, Arquiteto de Aplicativos

Quando possível e relevante, federe o Oracle Cloud Infrastructure Identity and Access Management com o provedor de identidades centralizado da sua organização (IdP).

Crie um grupo de administradores de federação que mapeie para o grupo de administradores do IdP federado e seja controlado pelas mesmas políticas de segurança que o grupo de administradores do IdP federado.
Crie usuários locais e designe os usuários aos grupos padrão do IAM Administrators, IAM Administrators e Credential Administrators. Use esses usuários para cenários de emergência (por exemplo, incapacidade de acessar recursos por meio de federação).
Defina uma política para impedir que o grupo do IAM dos administradores federados modifique a associação dos grupos Administrators da tenancy padrão.
Detecte acesso e operações não autorizados monitorando os logs de auditoria para operações por administradores de tenancy e alterações nos grupos Administrators.

Monitorar e Gerenciar as Atividades e o Status de Todos os Usuários

Arquiteto Enterprise, Arquiteto de Segurança, Arquiteto de Aplicativos

Monitore e gerencie as atividades e o status de todos os usuários.

Quando um funcionário sair da organização, desative o acesso à tenancy excluindo o usuário imediatamente.
Imponha a rotação da senha do usuário, chaves de API e todos os recursos de usuário relacionados à autenticação, a cada 90 dias ou menos.
Certifique-se de que as credenciais do IAM (Identity and Access Management) não estejam codificadas em nenhuma documentação de software ou operações.
Crie um usuário do IAM para todos na organização que precisam de acesso aos recursos na tenancy. Não compartilhe um usuário do IAM entre vários usuários humanos.
Implemente sign-on único federado para simplificar o acesso a vários aplicativos e centralizar a autenticação.
Revise os usuários nos grupos do IAM periodicamente e remova os usuários que não precisam mais de acesso.