Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Ejemplos de políticas de control de recursos
Los ejemplos de políticas de control de recursos (RCPs) que se muestran en este tema tienen únicamente fines informativos. Para ver ejemplos del perímetro de datos, consulte los ejemplos de políticas del perímetro de
Antes de usar estos ejemplos
Antes de usar estos ejemplos RCPs en su organización, haga lo siguiente:
-
Revise y personalice detenidamente RCPs para sus requisitos únicos.
-
Pruébelo minuciosamente RCPs en su entorno con los AWS servicios que utiliza.
Los ejemplos de políticas de esta sección demuestran la implementación y el uso de RCPs. Ellas no son destinadas a ser interpretadas como recomendaciones AWS oficiales o prácticas óptimas que se apliquen exactamente como se indica. Es su responsabilidad probar cuidadosamente cualquier política para determinar su idoneidad para resolver los requisitos empresariales de su entorno. Las políticas de control de recursos basadas en la denegación pueden limitar o bloquear involuntariamente el uso de AWS los servicios, a menos que añada las excepciones necesarias a la política.
Ejemplos generales
Temas
RCPFullAWSAccess
La siguiente política es una política AWS administrada y se adjunta automáticamente a la raíz de la organización, a todas las unidades organizativas y a todas las cuentas de la organización cuando se activan las políticas de control de recursos (). RCPs No se puede desvincular esta política. Este RCP predeterminado permite que todos los directores y las acciones accedan a sus recursos, lo que significa que, hasta que comience a crear y adjuntar RCPs, todos sus permisos de IAM existentes seguirán funcionando como antes. No necesita probar el efecto de esta política, ya que permitirá que el comportamiento de autorización existente continúe con sus recursos.
Protección cruzada contra la protección entre servicios
Algunos Servicios de AWS (los servicios de llamadas) utilizan su Servicio de AWS principal para acceder a AWS los recursos de otros Servicios de AWS (los denominados servicios). Cuando un actor que no tenía la intención de tener acceso a un AWS recurso intenta utilizar la confianza de un Servicio de AWS director para interactuar con recursos a los que no estaba destinado a tener acceso, se conoce como el problema del diputado confuso entre servicios. Para obtener más información, consulte El problema del suplente confuso en la Guía del usuario de IAM
La siguiente política exige que Servicio de AWS los directores que accedan a sus recursos solo lo hagan en nombre de las solicitudes de su organización. Esta política aplica el control únicamente a las solicitudes que tengan presente aws:SourceAccount, de modo que las integraciones de servicios que no requieran el uso de aws:SourceAccount no se vean afectadas. Si aws:SourceAccount está presente en el contexto de la solicitud, se evaluará la condición Null como true, lo que provocará que se aplique la clave aws:SourceOrgID.
Restringir el acceso solo a las conexiones HTTPS a sus recursos
La siguiente política exige que el acceso a los recursos se produzca únicamente en conexiones cifradas a través de HTTPS (TLS). Esto evita que posibles atacantes manipulen el tráfico de la red.
Controles de la política de bucket de Amazon S3
La siguiente RCP contiene varias instrucciones para aplicar controles de acceso coherentes en los buckets de Amazon S3 de su organización.
-
El ID de la instrucción
EnforceS3TlsVersion: requiere como mínimo la versión 1.2 de la TLS para poder acceder a buckets de S3. -
El ID de la instrucción
EnforceKMSEncryption: requiere que los objetos estén cifrados en el servidor con claves KMS.