Scopes y Estrategia de Segmentación

En el artículo sobre Inventory, vimos que los Scopes son filtros guardados que agrupan recursos de forma lógica. Pero el Scope no es solo una conveniencia de organización — es una de las piezas más críticas de seguridad en toda la configuración de Apono. Es el Scope el que define la superficie de ataque de cada Access Flow.

El Problema: Flows Sin Scope

Imagina el escenario de configuración más simple: creas un Access Flow apuntando directamente a la integración AWS, sin ningún Scope. El flow permite que ingenieros del equipo de backend soliciten acceso a recursos de AWS con aprobación del gestor.

¿Qué sucede en la práctica?

Cuando un ingeniero abre el portal de Apono para solicitar acceso, ve todos los recursos de la integración AWS: todas las instancias EC2, todas las bases de datos RDS, todos los buckets S3, todas las cuentas de la Organization. El flow no filtra nada — solo exige una aprobación.

El problema no es solo que el ingeniero pueda solicitar acceso a recursos críticos, sino también que ve que esos recursos existen. La visibilidad ya es un riesgo. Un ingeniero que no debería saber de la existencia de una base de datos con datos PII en una cuenta de compliance ahora sabe que existe, cuál es su nombre y que puede pedir acceso.

Y la única barrera entre él y ese acceso es la aprobación del gestor.

La Realidad de las Aprobaciones

En teoría, el gestor debería evaluar cada solicitud cuidadosamente: verificar si el ingeniero realmente necesita ese acceso, si el recurso es el correcto, si el nivel de permiso es adecuado y si la duración es razonable. En escenarios más críticos, lo ideal sería además consultar al equipo de compliance o GRC (Gobernanza, Riesgo y Cumplimiento) para garantizar que el acceso cumple con las políticas internas y regulatorias.

En la práctica, la mayoría de los aprobadores simplemente aprueban. Las razones son predecibles:

• El ingeniero dice que lo necesita para resolver un incidente y hay presión para desbloquear rápido.
• El aprobador es el gestor del equipo y confía en su gente.
• La solicitud llega por Slack y aprobar es un clic.
• El aprobador no tiene contexto técnico para evaluar si ese nivel de acceso es realmente necesario.
• Involucrar compliance o GRC en cada solicitud haría el proceso demasiado lento para el día a día.

Esto no elimina la responsabilidad de los aprobadores — siguen siendo una pieza importante del proceso. Pero depender exclusivamente de aprobación humana bajo presión es un control frágil. Scopes y Access Flows bien configurados reducen el margen de error y garantizan que, incluso cuando el aprobador aprueba rápido, el acceso concedido ya está dentro de límites seguros.

La aprobación debe ser el último filtro, no el único. Los aprobadores son responsables de la decisión, pero los Scopes y Access Flows existen para que esa decisión ocurra dentro de un perímetro seguro.

Cómo los Scopes Resuelven el Problema

Un Scope limita lo que un Access Flow puede conceder. Actúa como un filtro en el inventario que define qué recursos están dentro del alcance de ese flow. Los recursos fuera del Scope simplemente no aparecen para el solicitante — no puede pedir acceso a lo que no ve.

Con Scopes bien definidos:

• El ingeniero de backend que necesita acceder a EC2 en desarrollo solo ve instancias de desarrollo.
• El DBA que necesita acceder a bases de producción solo ve bases de producción y pasa por un flujo de aprobación diferente.
• Los recursos de compliance, seguridad o infraestructura crítica no aparecen en ningún flow de ingeniería.

Incluso si el aprobador aprueba sin pensar, el daño está limitado a lo que el Scope permite. El blast radius de una aprobación descuidada queda contenido por el scope.

Vale recordar que un mismo usuario — o grupo de usuarios — puede estar asociado a más de un Access Flow. En ese caso, los accesos disponibles se suman: puede solicitar todo lo que cada flow permite. La diferencia entre los flows puede estar en los aprobadores, los recursos visibles o el nivel de permiso concedido por cada Scope.

Estrategia de Segmentación

La forma en que defines tus Scopes determina el nivel de seguridad de toda la operación de Apono. Una buena estrategia de segmentación sigue dos ejes: ambiente y criticidad.

Eje 1: Por Ambiente o Cuenta AWS

La segmentación más básica e indispensable. Los recursos de producción y desarrollo nunca deben estar en el mismo Scope.

En la práctica, muchas empresas utilizan múltiples cuentas AWS para separar ambientes — una cuenta para desarrollo, otra para staging y otra para producción. Esta es una recomendación de la propia AWS (AWS Organizations con estrategia multi-account). Cuando la organización sigue este modelo, el Scope puede definirse directamente por la cuenta AWS en lugar de depender de tags de ambiente:

Scope	Filtro	Flow Asociado
EC2 Desarrollo	Cuenta 111111111111 (dev) + ResourceType=EC2	Auto-aprobación, 8 horas
EC2 Staging	Cuenta 222222222222 (staging) + ResourceType=EC2	Aprobación del gestor, 4 horas
EC2 Producción	Cuenta 333333333333 (prod) + ResourceType=EC2	Aprobación del gestor + security, 2 horas

Si la empresa usa una única cuenta AWS para todos los ambientes, la segmentación depende de tags como Environment=production. Pero en organizaciones con cuentas separadas, la cuenta en sí ya es el filtro más confiable — no hay riesgo de que alguien olvide aplicar un tag y el recurso termine en el Scope equivocado.

Las empresas que usan AWS Organizations con múltiples cuentas tienen una ventaja natural: la separación de ambientes ya está en la estructura de las cuentas. Incluso con una única integración en la cuenta principal, los Scopes pueden filtrar recursos por cuenta, haciendo la segmentación más robusta y menos dependiente de tags.

Con esta segmentación, el ingeniero que necesita hacer troubleshooting en dev obtiene acceso rápido sin esperar aprobación. Pero para producción, el flow exige más rigor. Y el Scope garantiza que, incluso con auto-aprobación en dev, nunca accede a producción por ese flow.

Eje 2: Por Criticidad

Dentro de un mismo ambiente, no todos los recursos tienen el mismo nivel de riesgo. Una base de datos con datos de clientes (PII) es más sensible que un cache Redis. Un bucket S3 con backups de base de datos es más crítico que un bucket con assets estáticos de un sitio web:

Scope	Filtro	Flow Asociado
RDS Producción — PII	Environment=production + DataClassification=pii	Aprobación del DBA + compliance, 1 hora, solo SELECT
RDS Producción — Interno	Environment=production + DataClassification=internal	Aprobación del DBA, 2 horas
RDS Dev	Environment=development + ResourceType=RDS	Auto-aprobación, 4 horas
S3 Producción — Sensible	Environment=production + DataClassification=sensitive	Aprobación del gestor + security, 1 hora, solo ReadOnly
S3 Producción — Público	Environment=production + DataClassification=public	Aprobación del gestor, 4 horas
S3 Dev	Environment=development + ResourceType=S3	Auto-aprobación, 8 horas

Observa que los mismos buckets S3 en el mismo ambiente de producción tienen flows completamente diferentes dependiendo del tag DataClassification. Un bucket con backups de base de datos, logs con datos personales o exports de reportes financieros exige un control mucho más estricto que un bucket que sirve imágenes de un sitio público.

Combinando los Ejes

En la práctica, los dos ejes se combinan para formar una matriz de Scopes que cubre toda la organización:

Cuanto más a la derecha y arriba en la matriz, más restrictivo debe ser el flow: más aprobadores, menor duración, permisos más granulares.

Ejemplo Práctico

Una organización con 3 cuentas AWS (dev, staging, producción) y 2 equipos (backend, data) puede configurar:

Scopes:

• ec2-dev — EC2 en las cuentas de desarrollo
• ec2-staging — EC2 en las cuentas de staging
• ec2-prod — EC2 en las cuentas de producción
• rds-dev — RDS en las cuentas de desarrollo
• rds-prod-internal — RDS de producción con DataClassification=internal
• rds-prod-pii — RDS de producción con DataClassification=pii
• s3-dev — S3 en las cuentas de desarrollo
• s3-prod-public — S3 de producción con DataClassification=public
• s3-prod-sensitive — S3 de producción con DataClassification=sensitive

Access Flows:

Flow	Quién Puede Solicitar	Scope	Aprobación	Duración
Dev EC2	Backend + Data	ec2-dev	Auto-aprobación	8h
Staging EC2	Backend + Data	ec2-staging	Gestor	4h
Prod EC2	Backend	ec2-prod	Gestor + SRE	2h
Dev RDS	Data	rds-dev	Auto-aprobación	4h
Prod RDS (interno)	Data	rds-prod-internal	Gestor + DBA	2h
Prod RDS (PII)	Data	rds-prod-pii	Gestor + DBA + Compliance	1h, solo SELECT
Dev S3	Backend + Data	s3-dev	Auto-aprobación	8h
Prod S3 (público)	Backend	s3-prod-public	Gestor	4h
Prod S3 (sensible)	Data	s3-prod-sensitive	Gestor + Security	1h, solo ReadOnly

El ingeniero de backend nunca ve bases de datos RDS en ningún flow. El ingeniero de data nunca ve EC2 de producción. Y los buckets S3 con datos sensibles solo son accesibles para el equipo de data con aprobación de security. Incluso dentro de los flows que cada uno puede acceder, el Scope limita los recursos visibles.

La Importancia de los Tags en AWS

No toda segmentación depende exclusivamente de tags. Si la empresa ya tiene cuentas AWS separadas por ambiente, la propia estructura de cuentas sirve como filtro. Si los recursos siguen una convención de nomenclatura clara (ej: prod-api-rds-01, dev-worker-ec2-03), el nombre del recurso ya ayuda a diferenciarlos. Pero en la práctica, pocas organizaciones tienen una arquitectura tan bien organizada. Los tags existen justamente para compensar esa falta de estructura — e incluso en ambientes bien diseñados, añaden una capa extra de clasificación que va más allá de lo que cuentas y nombres pueden expresar, como nivel de sensibilidad de los datos (DataClassification=pii) o equipo responsable (Team=data).

AWS Tag Editor: Tu Aliado

AWS ofrece el Tag Editor en la consola (Resource Groups & Tag Editor) que permite:

• Visualizar todos los recursos de una región y sus tags en una única pantalla
• Editar tags en masa — seleccionar múltiples recursos y aplicar el mismo tag de una vez
• Identificar recursos sin tags — filtrar por recursos que no poseen un tag específico
• Auditar la consistencia — verificar si todos los RDS de producción realmente tienen Environment=production

En la práctica, el proceso es:

1. Accede al Tag Editor en la consola de AWS
2. Filtra por tipo de recurso (ej: RDS, S3, EC2)
3. Identifica recursos sin los tags obligatorios
4. Selecciona los recursos y añade los tags faltantes en lote
5. Repite periódicamente — nuevos recursos creados sin tags rompen silenciosamente los Scopes de Apono

Tags e Infraestructura como Código

Lo ideal es que los tags se definan en la creación del recurso vía Terraform, CloudFormation u otra herramienta de IaC. Esto garantiza que todo recurso nace con los tags correctos:

# Ejemplo en Terraform
resource "aws_db_instance" "customers" {
  # ... configuración del RDS

  tags = {
    Environment        = "production"
    DataClassification = "pii"
    Team               = "data"
    Service            = "customers-db"
  }
}

resource "aws_s3_bucket" "reports" {
  # ... configuración del bucket

  tags = {
    Environment        = "production"
    DataClassification = "sensitive"
    Team               = "data"
    Service            = "financial-reports"
  }
}

Sin este patrón, dependes de que alguien recuerde añadir tags manualmente — y la experiencia demuestra que esto no funciona de forma consistente. Un recurso sin tags no desaparece de Apono — sigue en el inventario de la integración. El riesgo es que escape de los filtros de los Scopes, pudiendo aparecer en flows genéricos donde no debería estar, o no ser capturado por ningún Scope específico que dependa de tags para la segmentación.

Errores Comunes

1. Scope único para toda la integración

Un Scope que apunta a "todos los recursos de la integración AWS" es lo mismo que no tener Scope. Toda la seguridad que Apono ofrece depende de una segmentación adecuada.

2. Scopes basados solo en tipo de recurso

Crear un Scope "todos los EC2" o "todos los RDS" sin diferenciar por ambiente o criticidad pone producción y desarrollo en el mismo saco. El aprobador se acostumbra a aprobar todo porque la mayoría de las solicitudes son para dev, y cuando aparece una solicitud de producción, aprueba automáticamente.

3. No actualizar Scopes cuando la infraestructura cambia

Los Scopes basados en tags son dinámicos y se actualizan automáticamente. Pero si la estrategia de tagging cambia (ej: Environment pasa a ser env), los Scopes quedan vacíos silenciosamente. Monitorea periódicamente si los Scopes están capturando los recursos esperados.

4. Delegar la seguridad solo al aprobador

Si tu modelo de seguridad depende de que el gestor rechace solicitudes indebidas, ya has perdido. Los Scopes existen para garantizar que solicitudes indebidas no sean posibles, independientemente de quién aprueba.

La configuración de Scopes es trabajo de los administradores de Apono, no de los aprobadores. Quien define los Scopes define la superficie de ataque de toda la organización. Invierte tiempo en esta configuración — es la decisión de seguridad más impactante que tomarás en Apono.