Blog de Amazon Web Services (AWS)
Automatización del ciclo de vida de Service Control Policies a escala
Por Rayco Martínez, Head of Cloud Governance / Cloud CoE en Moeve; Jonatan De Martín, Cloud Engineer en Keepler Data Tech, centrado en AWS y Gonzalo Guerrero, Technical Account Manager en AWS.
Moeve, anteriormente conocida como Cepsa, es una compañía energética global que opera un entorno AWS multi-cuenta compuesto por cientos de cuentas distribuidas entre diferentes unidades organizativas (OU) y casos de uso. AWS Organizations y AWS Control Tower constituyen elementos fundamentales de este modelo, proporcionando la base para estructurar, aprovisionar y gobernar las cuentas AWS de forma centralizada.
Dentro de esta arquitectura, las Service Control Policies (SCPs) son uno de los principales mecanismos utilizados por Moeve para establecer controles preventivos. Las SCPs permiten definir el conjunto de permisos máximos disponibles para cuentas y Organizational Units (OUs), estableciendo restricciones corporativas relacionadas con seguridad, cumplimiento normativo y protección de servicios críticos.
Sin embargo, gestionar SCPs a escala plantea un problema de ingeniería adicional. A medida que crece el número de cuentas, equipos y casos de uso, no solo es necesario definir correctamente las políticas, sino que también hay que determinar dónde deben aplicarse, controlar su ciclo de vida, validar los cambios antes de desplegarlos y limitar el alcance de posibles errores.
Para abordar este reto, Moeve, en colaboración con Keepler, partner de AWS Partner Network (APN), y AWS, diseñó un modelo que combina controles heredados desde OU con controles específicos a nivel de cuenta. La solución desacopla la definición de las SCPs de sus asociaciones, mantiene ambos elementos como código y utiliza GitHub Actions para validar y desplegar los cambios sobre AWS Organizations.
Este modelo se integra con el aprovisionamiento de cuentas mediante AWS Control Tower y una capa adicional de automatización basada en AWS Cloud Development Kit (AWS CDK), permitiendo determinar y aplicar los controles correspondientes desde el onboarding de una nueva cuenta.
En este blog analizamos la implementación técnica de este modelo, cómo se determina el ámbito de aplicación de las SCPs y cómo se representan políticas y asociaciones como código. También analizamos cómo se reconcilia ese estado con AWS Organizations mediante un pipeline plan → approval → apply, y cómo se integran el onboarding, las excepciones y la observabilidad dentro del ciclo de vida de gobierno.
Requisitos previos
Para implementar una solución similar a la descrita en este blog, se recomienda disponer de:
- Una organización de AWS Organizations con todas las funcionalidades y las SCPs habilitadas.
- Una cuenta de administrador delegado para la gestión de políticas de Organizations (o alternativamente, acceso a la cuenta de administración).
- Un repositorio de GitHub con GitHub Actions y un proveedor de identidad OpenID Connect (OIDC) configurado en AWS Identity and Access Management (IAM).
- Conocimientos de evaluación de políticas IAM y SCPs, Python y AWS CDK.
El reto de gobernar SCPs a escala
AWS Organizations permite asociar SCPs a diferentes niveles de la jerarquía organizativa y hacer que las cuentas hereden las políticas aplicadas sobre sus OUs. Este modelo funciona especialmente bien para controles estables que deben aplicarse de forma homogénea a conjuntos amplios de cuentas.
Sin embargo, una OU no representa necesariamente todas las dimensiones que determinan qué controles necesita cada carga de trabajo. Dos cuentas dentro de una misma OU pueden tener diferentes propósitos, requisitos de seguridad o necesidades operativas.
Esta diferencia se vuelve especialmente relevante al modificar una política compartida. Si una SCP está asociada a una OU que contiene decenas o cientos de cuentas, cualquier cambio puede afectar al conjunto de permisos disponible para todas ellas. Cuanto mayor sea el número de cuentas afectadas por una asociación, mayor será el impacto potencial de cualquier cambio en la política.
Por ejemplo, un equipo puede necesitar evaluar un nuevo servicio AWS que todavía no forma parte del baseline corporativo. Modificar una SCP compartida para resolver esa necesidad podría alterar los controles de todas las cuentas que heredan la política. Mover temporalmente la cuenta a otra OU tampoco es necesariamente una solución: su posición en AWS Organizations puede determinar la herencia de otros controles no relacionados con el caso de uso.
En el extremo contrario, gestionar individualmente todas las asociaciones a nivel de cuenta reduciría el alcance de los cambios, pero trasladaría una complejidad operativa considerable a un entorno con cientos de cuentas.
El problema, por tanto, no consiste únicamente en automatizar el despliegue de SCPs, sino en encontrar un equilibrio entre herencia, granularidad y automatización. Para ello, Moeve desacopló dos conceptos fundamentales: qué control define una política y dónde debe aplicarse.
Modelo de control: estructura, contexto y excepción
La primera decisión de diseño fue determinar a qué nivel debía aplicarse cada control. Utilizar exclusivamente OUs simplificaba la herencia, pero aumentaba el alcance de los cambios. Aplicar todos los controles directamente sobre cuentas proporcionaba mayor granularidad, pero incrementaba considerablemente la complejidad de sus asociaciones.
Moeve adoptó un modelo híbrido en el que el ámbito de aplicación de una SCP depende de su propósito y ciclo de vida. El modelo diferencia tres categorías de controles.
SCPs estructurales
Las SCPs estructurales representan controles corporativos estables que deben aplicarse de forma homogénea a conjuntos de cuentas. Se asocian a OUs y utilizan el mecanismo de herencia de AWS Organizations para proporcionar un baseline común.
Este nivel se utiliza cuando el alcance del control coincide con la estructura organizativa. Al tratarse de políticas compartidas, cualquier modificación debe evaluarse teniendo en cuenta su impacto sobre las cuentas que las heredan.
SCPs contextuales
La posición de una cuenta dentro de una OU no siempre contiene toda la información necesaria para determinar sus controles. El propósito de la carga de trabajo o su contexto operativo pueden requerir restricciones adicionales.
Las SCPs contextuales complementan las políticas heredadas y se asocian directamente a las cuentas que las necesitan. Su selección puede realizarse durante el onboarding utilizando los metadatos asociados a la nueva cuenta.
Estas políticas no representan excepciones. Forman parte del baseline esperado para ese tipo de cuenta.
Por tanto, la estructura organizativa y el contexto actúan como dos dimensiones complementarias. La primera determina los controles heredados y la segunda permite añadir controles específicos sin trasladar toda la lógica de gobierno a la jerarquía de OUs.
SCPs de excepción temporal
El tercer escenario aparece cuando una cuenta necesita operar temporalmente con una combinación de controles diferente de su baseline, por ejemplo, para evaluar un nuevo servicio AWS o realizar una prueba controlada.
En estos casos, el cambio se gestiona mediante el mismo modelo declarativo utilizado para el resto de asociaciones, limitando su alcance a la cuenta afectada y evitando modificaciones innecesarias sobre controles compartidos.
La diferencia fundamental respecto a una SCP contextual es su ciclo de vida. Una política contextual forma parte del baseline esperado para ese tipo de cuenta, mientras que una variación temporal responde a una necesidad concreta y debe disponer de un mecanismo explícito de revisión y cierre.
Dependiendo de cómo estén definidos los controles existentes, esta variación puede materializarse mediante la adición, sustitución o retirada de asociaciones específicas dentro del modelo de gobierno.
Esta clasificación permite adaptar el alcance de cada política a su propósito. Las SCPs estructurales priorizan la herencia y consistencia; las contextuales proporcionan granularidad en función del tipo de cuenta; y las excepciones permiten introducir cambios controlados con un blast radius limitado.
Arquitectura de la solución
La arquitectura separa dos procesos con ciclos de vida diferentes que convergen sobre AWS Organizations:
- El onboarding de cuentas
- La gestión del ciclo de vida de las SCPs
El primer flujo comienza con el aprovisionamiento de una cuenta mediante AWS Control Tower. Una capa adicional de automatización basada en AWS CDK completa su onboarding y utiliza el contexto de la cuenta para determinar los controles específicos que deben aplicarse.
El segundo flujo gestiona la evolución de las políticas y sus asociaciones. Las definiciones de las SCPs y los mappings que determinan sus destinos se mantienen en un repositorio Git y los cambios se realizan mediante pull requests. GitHub Actions ejecuta el proceso de validación y despliegue, utilizando autenticación federada mediante OIDC para obtener credenciales temporales en AWS.
El pipeline separa las operaciones de lectura y modificación. Durante plan, el SCP Manager consulta AWS Organizations y compara el estado existente con el definido en Git. Tras la revisión y aprobación del cambio, apply utiliza un rol diferente para ejecutar las modificaciones necesarias.
Ambos flujos convergen sobre AWS Organizations, pero responden a necesidades diferentes. El onboarding determina qué controles necesita una nueva cuenta, mientras que el flujo GitOps controla cómo evolucionan posteriormente las políticas y sus asociaciones.
Esta separación permite incorporar nuevas cuentas al modelo de gobierno sin depender de operaciones manuales y, al mismo tiempo, mantener los cambios posteriores sobre las SCPs dentro de un proceso versionado, revisado y automatizado.
SCPs como código: separar definición y asignación
Una de las decisiones clave del modelo es desacoplar el contenido de una SCP de los destinos sobre los que debe aplicarse. Una política define qué se quiere controlar, mientras que su asociación determina dónde debe aplicarse ese control.
Ambos elementos se mantienen como código, pero de forma independiente. De manera simplificada, el repositorio utilizado por el SCP Manager puede representarse con la siguiente estructura:
.
├── scps/
│ ├── baseline-security.json
│ ├── genai-restrictions.json
│ └── example-policy.json
├── maps/
│ └── scps-to-targets.yaml
└── scp-manager/
└── push-scps.pyLos ficheros de scps/ contienen las definiciones de las políticas, mientras que el mapping mantiene sus asociaciones con cuentas u OUs. Por ejemplo:
scp_mappings:
- policy: baseline-security
target: ou-security
- policy: genai-restrictions
target: workload-account
- policy: example-policy
target: sandbox-accountEsta separación permite versionar independientemente dos tipos de cambio con implicaciones diferentes. Modificar el documento de una SCP puede alterar el control sobre todos los destinos donde ya está asociada; modificar el mapping cambia su ámbito de aplicación sin necesidad de alterar la definición de la política.
El repositorio representa así el estado deseado. Para reconciliarlo con AWS Organizations, Moeve y Keepler desarrollaron el SCP Manager, un componente propio escrito en Python que se ejecuta como parte del pipeline de GitHub Actions. El SCP Manager interpreta las definiciones y asociaciones almacenadas en Git y consulta AWS Organizations para conocer el estado actualmente desplegado.
Durante el despliegue, el SCP Manager compara el estado deseado definido en Git con el estado desplegado en AWS Organizations. Cada discrepancia entre ambos se traduce en una operación concreta: si el documento de una política ha cambiado en Git, actualiza la SCP; si el mapping incluye un destino nuevo, crea la asociación; si un destino ha desaparecido del mapping, elimina la asociación.
Este patrón permite pasar de un modelo imperativo, en el que un operador ejecuta los cambios directamente sobre AWS Organizations, a un modelo declarativo. En el modelo declarativo, el Cloud Center of Excellence (CCoE) define el estado deseado en el repositorio mediante pull requests: los ficheros de scps/ describen qué controles existen y el mapping describe dónde se aplican. El SCP Manager compara ese estado con AWS Organizations y determina las acciones necesarias para alcanzarlo.
El resultado es una base sobre la que aplicar prácticas habituales de ingeniería de software al plano de gobierno: control de versiones, revisión de cambios, validación y despliegues reproducibles.
Pipeline GitOps: plan → approval → apply
Mantener las SCPs como código resuelve cómo representar el estado deseado, pero no cómo desplegarlo de forma segura. Las SCPs forman parte del plano de control de AWS Organizations y una modificación incorrecta puede afectar simultáneamente a múltiples cuentas.
Por este motivo, Moeve estructura el despliegue mediante un flujo plan → approval → apply. La primera fase consulta el estado existente y calcula los cambios esperados sin modificar AWS Organizations. Tras la aprobación, el flujo dispone de capacidad para ejecutar únicamente las modificaciones necesarias.
El siguiente workflow simplificado muestra un ejemplo de este patrón.
name: SCP Governance Pipeline
on:
push:
branches: ["main"]
paths:
- "scps/**"
- "maps/scps-to-targets.yaml"
workflow_dispatch:
permissions:
id-token: write
contents: read
env:
AWS_REGION: ${{ vars.AWS_REGION }}
WORKING_DIRECTORY: scp-manager
jobs:
plan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.11"
- name: Install dependencies
run: pip install boto3 botocore PyYAML ruamel.yaml
- name: Configure AWS credentials with OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_SCP_PLAN_ROLE_ARN }}
role-session-name: scp-plan
aws-region: ${{ env.AWS_REGION }}
- name: Generate SCP deployment plan
working-directory: ${{ env.WORKING_DIRECTORY }}
run: python push-scps.py --plan --max-diff-lines 200
- name: Publish sanitized plan artifacts
uses: actions/upload-artifact@v4
with:
name: scp-deployment-plan
path: |
${{ env.WORKING_DIRECTORY }}/plan.md
${{ env.WORKING_DIRECTORY }}/diffs/*.diff
retention-days: 3
apply:
needs: plan
runs-on: ubuntu-latest
environment: governance-approval
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.11"
- name: Install dependencies
run: pip install boto3 botocore PyYAML ruamel.yaml
- name: Configure AWS credentials with OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_SCP_APPLY_ROLE_ARN }}
role-session-name: scp-apply
aws-region: ${{ env.AWS_REGION }}
- name: Apply SCP changes
working-directory: ${{ env.WORKING_DIRECTORY }}
run: python push-scps.pyPlan: calcular el impacto antes de modificar
El job plan utiliza un rol IAM destinado a las operaciones de lectura necesarias para consultar las SCPs y sus asociaciones en AWS Organizations.
El SCP Manager compara esta información con las definiciones y mappings almacenados en Git y genera una previsión del cambio. De esta forma, el pipeline puede identificar, por ejemplo, que una política necesita actualizarse o que una asociación debe añadirse o eliminarse antes de ejecutar la modificación.
El objetivo de esta fase es responder a una pregunta sencilla: si aplicamos el estado definido en Git, ¿qué cambiará en AWS Organizations?
El resultado puede almacenarse temporalmente como un plan y un conjunto de diferencias para facilitar su revisión. Estos artefactos también pueden contener información sensible sobre la estructura organizativa o los controles aplicados, por lo que el ejemplo utiliza una retención reducida y presupone que cualquier contenido destinado a publicación ha sido previamente sanitizado.
OIDC y separación de privilegios
La autenticación desde GitHub Actions se realiza mediante OpenID Connect (OIDC), evitando almacenar access keys de AWS de larga duración en GitHub.
El permiso id-token: write permite al workflow solicitar un token OIDC que AWS STS valida contra el proveedor de identidad OIDC de IAM antes de permitirle asumir el rol correspondiente. La trust policy del rol puede restringir qué identidades de GitHub Actions pueden asumirlo mediante las claims incluidas en el token OIDC, limitando, por ejemplo, el acceso a un repositorio, rama o GitHub Environment determinados.
Además, plan y apply no comparten el mismo rol IAM. El primero necesita observar el estado de AWS Organizations, pero no modificarlo. El segundo dispone únicamente de las acciones necesarias para gestionar las SCPs bajo responsabilidad del SCP Manager.
Esta separación aplica el principio de mínimo privilegio al propio pipeline y reduce las capacidades disponibles antes de que un cambio haya sido aprobado.
Approval: separar validación de autorización
La finalización correcta de plan no provoca automáticamente una modificación de AWS Organizations.
El job apply depende de plan y está asociado a un GitHub Environment protegido:
apply:
needs: plan
environment: governance-approvalEl Environment permite introducir una aprobación antes de continuar con el despliegue y restringir el acceso al rol utilizado durante apply.
De esta forma se separan dos decisiones distintas: el plan determina qué cambiaría; la aprobación determina si ese cambio puede ejecutarse.
Apply: ejecutar los cambios
Después de la aprobación, apply obtiene mediante OIDC una nueva sesión de AWS utilizando el rol de despliegue y ejecuta el SCP Manager para reconciliar el estado definido en el repositorio con el estado actual de AWS Organizations.
Dependiendo de la diferencia detectada entre el estado definido en Git y el estado existente, estas operaciones pueden incluir la actualización de una SCP o cambios en sus asociaciones con cuentas y OUs.
El resultado es un pipeline en el que los controles se distribuyen entre diferentes capas: Git proporciona versionado y revisión; plan permite evaluar el impacto esperado; el Environment protegido introduce autorización antes del despliegue; OIDC proporciona credenciales temporales; y la separación de roles limita los privilegios disponibles en cada fase.
La automatización, por tanto, no elimina los controles humanos sobre el plano de gobierno. Los incorpora dentro de un proceso reproducible, trazable y con privilegios diferenciados.
Onboarding automático y gestión de excepciones
El modelo de gobierno también se integra con el ciclo de vida de las cuentas. El objetivo es que una nueva cuenta se incorpore con los controles que le corresponden desde su onboarding, evitando que su configuración dependa de una intervención manual posterior.
El aprovisionamiento comienza mediante AWS Control Tower. Una vez creada la cuenta, una capa adicional de automatización basada en AWS CDK completa su configuración y utiliza información sobre su contexto para determinar las SCPs específicas que necesita.
Por ejemplo, de forma simplificada, una cuenta destinada a una carga de trabajo de inteligencia artificial generativa podría incorporar metadatos como:
account_metadata:
environment: prod
workload: genai
compliance: restrictedA partir de este contexto, el proceso de onboarding puede resolver un conjunto adicional de políticas:
resolved_scps:
- baseline-security
- genai-restrictions
- restricted-workload-controlsEstas políticas complementan los controles estructurales que la cuenta ya hereda desde su OU. De esta forma, la OU proporciona el baseline común mientras que el contexto permite añadir controles específicos sin trasladar toda la lógica de gobierno a la estructura de AWS Organizations.
Gestionar excepciones sin modificar el baseline compartido
El mismo principio de granularidad se utiliza cuando una cuenta necesita desviarse temporalmente de su baseline. Por ejemplo, un equipo puede necesitar evaluar un nuevo servicio AWS que requiere adaptar uno de los controles existentes.
En lugar de modificar controles compartidos asociados a una OU, la variación se limita a la cuenta afectada y se gestiona mediante el mismo proceso GitOps descrito anteriormente. El cambio queda así versionado, sujeto a revisión y aprobación, y con un blast radius limitado al target que realmente lo necesita.
Dependiendo de la implementación de los controles existentes, esta variación puede requerir modificar asociaciones específicas dentro del modelo de gobierno manteniendo la trazabilidad y el proceso de autorización establecidos.
Una excepción tiene además un ciclo de vida diferente del de una SCP contextual. Si la necesidad desaparece, la asociación temporal se elimina y la cuenta vuelve a su baseline. Si el caso de uso se valida como un patrón que debe aplicarse de forma estándar, el cambio puede evolucionar e incorporarse al baseline correspondiente.
De esta forma, las excepciones dejan de ser modificaciones puntuales fuera del modelo de gobierno y pasan a ser cambios controlados con un alcance y un mecanismo de cierre definidos.
Observabilidad y trazabilidad
El modelo GitOps proporciona trazabilidad sobre los cambios realizados a través del pipeline: qué modificación se propuso, cómo fue revisada y cuándo se desplegó. Moeve complementa esta información con observabilidad sobre las operaciones que se producen en AWS Organizations.
AWS CloudTrail registra la actividad sobre la organización y Amazon EventBridge permite filtrar eventos relevantes, que posteriormente pueden ser procesados mediante AWS Lambda para generar notificaciones al CCoE.
Entre los eventos monitorizados se encuentran la creación de nuevas cuentas, movimientos entre OUs y modificaciones en las asociaciones de SCPs. Esta capa proporciona visibilidad sobre el estado del plano de gobierno y complementa el historial disponible en Git y GitHub Actions.
La observabilidad también resulta relevante para las excepciones. Mientras una cuenta opera con una configuración diferente de su baseline, el CCoE puede mantener visibilidad sobre esa situación hasta que la excepción se elimina o evoluciona hacia un control estándar.
De esta forma, el modelo combina controles preventivos mediante SCPs con mecanismos de detección y trazabilidad sobre la evolución de la propia configuración de gobierno.
Resultados
Este modelo permite a Moeve gestionar aproximadamente 150 SCPs sobre más de 300 cuentas AWS, manteniendo políticas y asociaciones bajo un proceso centralizado de versionado, revisión y despliegue automatizado. El CCoE procesa en torno a 4.000 solicitudes de acceso al año sobre este entorno.
La combinación de controles heredados desde OUs y controles específicos a nivel de cuenta permite adaptar el alcance de las políticas a su propósito. Los controles estables pueden aplicarse de forma homogénea, mientras que necesidades específicas y excepciones pueden limitarse a las cuentas correspondientes, reduciendo el impacto potencial de cambios que no necesitan afectar al conjunto de la organización.
La automatización también permite incorporar nuevas cuentas al modelo de gobierno durante su onboarding y gestionar posteriormente la evolución de las SCPs mediante código, evitando que la operación habitual dependa de modificaciones manuales sobre AWS Organizations. Desde que el ciclo de vida de las SCPs se trasladó al pipeline, los cambios manuales en la consola de AWS Organizations se han reducido a cero, y con ellos los errores de configuración que esas acciones solían provocar.
Más allá del número de políticas o cuentas gestionadas, el resultado es un modelo en el que el crecimiento del entorno multi-cuenta no requiere un incremento equivalente del esfuerzo manual necesario para mantener sus controles organizativos.
Estos resultados amplían el programa de automatización de gobernanza que Moeve inició con AWS Control Tower en 2022: el tiempo de despliegue de cuentas se ha reducido un 75%, el sistema de notificaciones ha recortado un 45% el esfuerzo dedicado a la gobernanza cloud, y sus notificaciones han alcanzado una tasa de adopción superior al 85% entre los equipos de Moeve.
Conclusión
Gestionar SCPs a escala es un problema diferente a definir políticas individuales. Cuando crece el número de cuentas, controles y equipos, también es necesario gobernar cómo se representan las políticas, dónde se aplican, cómo se revisan sus cambios y qué identidades pueden desplegarlos.
La arquitectura desarrollada por Moeve aborda estas dimensiones combinando configuración declarativa, automatización y diferentes ámbitos de aplicación. Git representa el estado deseado; el pipeline permite evaluar los cambios antes de ejecutarlos; OIDC evita credenciales AWS de larga duración en GitHub; y la separación entre los roles de plan y apply aplica mínimo privilegio al propio proceso de gobierno.
Una de las principales lecciones de este modelo es que automatizar el plano de gobierno no implica eliminar controles. Al contrario, permite incorporarlos al proceso de ingeniería mediante control de versiones, revisión, aprobación, privilegios diferenciados y trazabilidad.
Este enfoque permite que el modelo de gobierno evolucione junto con el entorno multi-cuenta manteniendo un principio fundamental: los controles deben escalar mediante código y automatización, no mediante un crecimiento equivalente de las operaciones manuales.
Autores
 |
Rayco MartínezHead of Cloud Governance / Cloud CoE en Moeve. Rayco es un arquitecto Cloud con más de 20 años de experiencia en la industria energética, especializado en gobernanza cloud, cumplimiento normativo y transformación digital. Su pasión reside en diseñar e implementar soluciones cloud escalables, seguras y eficientes que impulsen la innovación empresarial. |
 |
Jonatan De MartínCloud Engineer en Keepler Data Tech, centrado en AWS, automatización y soluciones cloud. Trabaja en la construcción de plataformas cloud escalables y fiables, con especial interés en gobernanza cloud, observabilidad y automatización de infraestructura. Disfruta ayudando a los equipos a simplificar entornos complejos y a mejorar su forma de operar en la nube. |
 |
Gonzalo GuerreroTechnical Account Manager en AWS, ayuda a clientes Enterprise mediante guía técnica estratégica. A lo largo de sus 10 años en Amazon ha contribuido en múltiples divisiones, entre ellas HR, IT, Alexa, Amazon Business y AWS, obteniendo una visión amplia del panorama tecnológico. Fuera del trabajo, Gonzalo disfruta jugando al voleibol con su mujer y explorando el mundo junto a su Boston Terrier, Tigre. |