Seguridad

La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferir

Una exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.

約 7 分で読めます

¿Por qué números de 12 dígitos?

Un ID de cuenta de AWS es un número de 12 dígitos (por ejemplo: 123456789012). Esta longitud fue diseñada para garantizar que AWS pueda emitir un número suficiente de cuentas en el futuro. Un número de 12 dígitos proporciona 10^12 = 1 billón de combinaciones posibles. Hasta 2024, el número de cuentas activas de AWS no se ha divulgado públicamente, pero las estimaciones oscilan entre decenas de millones y cientos de millones. Con un espacio de 1 billón, los ID no se agotarán durante cientos de años al ritmo de crecimiento actual. La razón por la que los ID de cuenta consisten solo en dígitos es la compatibilidad y la legibilidad. Los ID compuestos únicamente por dígitos pueden procesarse sin problemas en cualquier sistema o lenguaje de programación, y son menos propensos a malentendidos cuando se comunican verbalmente por teléfono. Sin embargo, dado que existen ID de cuenta con ceros iniciales (por ejemplo: 012345678901), es necesario almacenar los ID de cuenta como cadenas de texto en los programas. Almacenarlos como enteros provoca la pérdida de los ceros iniciales, resultando en un número de 11 dígitos. Esta trampa es uno de los primeros errores que encuentran los desarrolladores al comenzar con AWS.

Estructura del ARN - El sistema de direcciones para los recursos de AWS

Cada recurso de AWS se identifica de forma única mediante un ARN (Amazon Resource Name). El formato del ARN es arn:partition:service:region:account-id:resource-type/resource-id. Esta estructura refleja la arquitectura de AWS. La partición es aws en la mayoría de los casos, pero las regiones de China usan aws-cn y GovCloud usa aws-us-gov, lo que indica que China y GovCloud operan en infraestructura completamente independiente de otras regiones. El servicio es el nombre del servicio (s3, ec2, lambda, etc.), y la región es el código de región (ap-northeast-1, etc.). Para los servicios globales (IAM, Route 53, CloudFront, etc.), la región está vacía. El account-id es el ID de cuenta de 12 dígitos que identifica al propietario del recurso. Los ARN de buckets de S3 (arn:aws:s3:::my-bucket) no incluyen un ID de cuenta. Esto se debe a que los nombres de buckets de S3 son globalmente únicos, por lo que el recurso puede identificarse sin un ID de cuenta. Este diseño se decidió en los inicios de S3; los servicios posteriores siempre incluyen el ID de cuenta.

¿Es el ID de cuenta información secreta?

Un ID de cuenta de AWS no es estrictamente información secreta, pero tampoco debería exponerse innecesariamente. Conocer un ID de cuenta por sí solo no otorga acceso a los recursos de esa cuenta. El acceso requiere credenciales de IAM (claves de acceso o AssumeRole para un rol). Sin embargo, si un ID de cuenta se hace público, surgen varios riesgos. En primer lugar, puede utilizarse como material para ingeniería social. Dado que los ID de cuenta se usan como parte de la verificación de identidad al contactar con AWS Support, un atacante que conozca el ID de cuenta tiene mayor probabilidad de éxito en la suplantación de identidad. En segundo lugar, existe el riesgo de explotar políticas basadas en recursos mal configuradas. Si una política de bucket de S3 especifica un ID de cuenta en el Principal, un atacante que conozca ese ID de cuenta puede intentar AssumeRole desde su propia cuenta. En tercer lugar, existe el riesgo de explotar configuraciones incorrectas de compartición de AMI o snapshots. Si una AMI está configurada para compartirse con un ID de cuenta específico, la filtración de ese ID de cuenta podría resultar en una compartición no intencionada.

Vías por las que los ID de cuenta se filtran involuntariamente

Los ID de cuenta pueden filtrarse externamente sin que los desarrolladores sean conscientes. La vía más común es cuando los ARN de roles o usuarios de IAM se incluyen en logs o mensajes de error. Al enviar logs de CloudTrail a servicios externos de análisis de logs, los ID de cuenta dentro de los logs se transmiten tal cual. Las plantillas de CloudFormation o el código de Terraform subidos a GitHub frecuentemente contienen ID de cuenta codificados directamente. Aunque una URL de bucket de S3 (https://my-bucket.s3.amazonaws.com) no revela directamente el ID de cuenta, los mensajes de error de políticas de bucket pueden contenerlo. El ID de cuenta también puede obtenerse del servicio de metadatos de EC2 (http://169.254.169.254/latest/meta-data/identity-credentials/ec2/info), por lo que si existe una vulnerabilidad SSRF (Server-Side Request Forgery), el ID de cuenta puede filtrarse. Forzar el uso de IMDSv2 (Instance Metadata Service Version 2) previene la obtención de metadatos mediante SSRF.

Estrategia multi-cuenta y gestión de ID de cuenta

En las operaciones modernas de AWS, una estrategia multi-cuenta donde una sola organización gestiona decenas a cientos de cuentas es el estándar. Usando AWS Organizations, se pueden crear OU (Organizational Units) bajo la cuenta raíz de la organización y gestionar las cuentas de forma jerárquica. A cada cuenta se le asigna un ID único de 12 dígitos, y el uso compartido de recursos entre cuentas se controla mediante RAM (Resource Access Manager) y políticas basadas en recursos. En una estrategia multi-cuenta, la gestión de los ID de cuenta se convierte en un desafío operativo. Con cientos de cuentas, resulta difícil rastrear qué ID de cuenta corresponde a qué entorno (producción, staging, desarrollo). Se recomienda usar la función de etiquetado de AWS Organizations para adjuntar metadatos a las cuentas y mantener una tabla de correspondencia entre ID de cuenta y nombres de cuenta. Usar Control Tower proporciona un flujo de trabajo estandarizado donde las etiquetas se aplican automáticamente y los guardrails (SCP) se aplican cuando se crean las cuentas. Para un enfoque sistemático de la gestión de cuentas de AWS y el diseño de seguridad, los libros especializados (Amazon) son una referencia útil.

Servicios relacionados

AWS IAMServicio de autenticación y autorización para gestionar de forma segura el acceso a los recursos de AWSAWS OrganizationsServicio para gestionar centralmente múltiples cuentas de AWS

Artículos relacionados

Diseño de gestión de identidad y acceso - Lograr seguridad Zero Trust con IAMAprende técnicas de diseño de gestión de acceso con AWS IAM, incluyendo el principio de mínimo privilegio, diseño de políticas y lograr seguridad Zero Trust mediante integración con Cognito.Capacidad de diseño de gobernanza multi-cuenta en AWS - Gobernanza organizacional con Organizations, Control Tower y SCPComparamos el mecanismo de gobernanza multi-cuenta centrado en AWS Organizations, Control Tower y SCP (Service Control Policies) con Azure Management Groups, explicando la diferencia en capacidad de diseño de gobernanza empresarial.Gestión multi-cuenta con AWS Organizations - Diseño de OU y aplicación de políticas de control de serviciosExplicación de la gestión multi-cuenta con AWS Organizations. Se presenta el diseño de OU, la aplicación de SCP, la integración con Control Tower y la facturación consolidada.

Más sobre este tema

Detección de permisos excesivos con IAM Access Analyzer - Análisis de acceso externo y permisos no utilizadosDetecta permisos no utilizados en roles IAM mediante análisis basado en CloudTrail y genera automáticamente políticas de mínimo privilegio. Cubre la detección de acceso externo y la integración de verificaciones de políticas personalizadas en pipelines CI/CD.Automatización de la gestión de certificados SSL/TLS con AWS Certificate Manager - Desde la emisión hasta la rotaciónExplicamos la emisión gratuita de certificados públicos con ACM, la validación DNS, la renovación automática y el despliegue en ALB y CloudFront.Obtención de informes de cumplimiento con AWS Artifact - Respuesta a auditorías y gestión de contratosPresenta cómo obtener informes de auditoría SOC, PCI DSS e ISO bajo demanda, y aplicar BAA y GDPR DPA de forma masiva a toda la organización con Organizations.Automatización de auditorías - Recopilación continua de evidencias de cumplimiento con AWS Audit ManagerExplica la recopilación automática de evidencias de auditoría con AWS Audit Manager. Presenta la evaluación automática basada en frameworks (SOC 2, PCI DSS, GDPR, etc.), gestión centralizada de evidencias y generación de informes de auditoría.Por qué el usuario root de una cuenta AWS es peligroso - Filosofía de diseño de separación de privilegios y práctica de selladoExplicamos por qué el usuario root de AWS tiene privilegios que IAM no puede restringir, la lista de operaciones que solo el usuario root puede realizar, cómo configurar MFA y la estrategia de sellado mediante la gestión de acceso root de Organizations.Gestión de certificados y HTTPS - Operaciones automatizadas de certificados TLS con AWS Certificate ManagerAprenda sobre la emisión de certificados TLS/SSL, renovación automática y despliegue usando AWS Certificate Manager (ACM). Cubre la integración con CloudFront, ALB y API Gateway, validación DNS y uso de Private CA.Gestión dedicada de claves con AWS CloudHSM - Cifrado compatible con FIPS 140-2 Level 3Logre gestión de claves compatible con FIPS 140-2 Level 3 con instancias HSM dedicadas. Aprenda cuándo elegir CloudHSM sobre KMS y cómo integrar ambos mediante almacenes de claves personalizados de KMS.CloudTrail lo ve todo - Mecanismo de registro de llamadas API y práctica de investigación forenseExplicamos cómo CloudTrail registra las llamadas a la API de AWS, las diferencias entre eventos de administración y eventos de datos, el análisis SQL con CloudTrail Lake y las técnicas de investigación forense ante incidentes de seguridad.

Artículos y servicios similares

Gestión multi-cuenta con AWS Organizations - Diseño de OU y aplicación de políticas de control de serviciosExplicación de la gestión multi-cuenta con AWS Organizations. Se presenta el diseño de OU, la aplicación de SCP, la integración con Control Tower y la facturación consolidada.Diseño multi-cuenta de Amazon VPC Lattice - Patrones de configuración con RAM y redes de serviciosExplicamos el diseño de compartición con RAM, la estrategia de segmentación de redes de servicios y el diseño jerárquico de Auth Policy para operar VPC Lattice en entornos multi-cuenta.La identidad del metadato EC2 169.254.169.254 - Dirección link-local y diseño de IMDSv2Explicamos por qué el endpoint del servicio de metadatos de instancias EC2 169.254.169.254 es una dirección link-local, la historia de su explotación en ataques SSRF, y las circunstancias que llevaron a la creación de la autenticación basada en tokens de IMDSv2.Por qué los Availability Zone ID de AWS difieren por cuenta - La intención de diseño detrás del mapeo de AZExplicamos cómo us-east-1a apunta a diferentes AZ físicas por cuenta, por qué se introdujeron los AZ ID (use1-az1), la intención de diseño de distribución uniforme de capacidad y las consideraciones para la especificación de AZ entre cuentas.Compartición de recursos entre cuentas con AWS RAM - Subnets VPC y Transit Gateway compartidosComparte recursos AWS entre cuentas de la organización sin duplicarlos. Presentamos la compartición de subnets VPC, Transit Gateway, Route 53 Resolver Rules y otros recursos.