Iba siendo hora de aplicar ya un poco de “best practices” a esta la cuenta de un servidor. El primer paso antes de raelizar cualquier otro cambio, era aplicar AWS Organizations. Qué es AWS Organizations te preguntarás? JE, buena pregunta.
AWS Organizations 101
AWS Organizations es un servicio adminstrado de cuentas que te permite consolidar multiples cuentas de AWS en una “organización” que tu creas y administras centralmente. Incluye administración de cuentas y consolidación de facturación que te permite cumplir mejor con el presupuesto, seguridad y necesidades de cumplimiento de tu negocio. Puedes crear cuenta directamente desde AWS desde Organizations o invitar cuentas que ya existan que se añadan a tu organización.
Características de AWS Organizations
- Administración central de todas las cuentas
- Facturación central de todas las cuentas
- Puedes pagar centralmente el gasto de todas las cuentas
- Puedes acceder al gasto creado por cada una de las cuentas que pertenecen a la organización
- Agrupación jerarquica de tus cuentas para cumplir objetivos de presupuesto, seguridad y necesidades de cumplimiento
- Permie agrupar las cuentas en OU
- OU, aka, Organizational Units y adjuntar diferentes politícas de seguridad
- Políticas para centralizar el control de sobre servicios de AWS y acciones de API que cada cuenta puede hacer
- Puedes usar SCP (Service Control Policies) para especificar el máximo de permisos para cuentas miembro dentro de la organización
- Políticas para estandarizar el uso de tags en los recursos de cualquier cuenta
- Políticas para controlar como la inteligencia artficial de AWS y los servicios de machine learning colectan y guardan los datos
- Políticas que configuran las copia de respaldo automáticas para los recursos de tu organización
- Integración con IAM
- control granular sobre usuarios y roles en cuentas indiviudales
- Acceso Global
- No es un servicio regional
- Replicación de datos que es eventualmente consistente.
- Internamente, AWS Organizations necesita replicar sus datos en múltiples localizaciones, para luego guardar el cambio de manera segura.
- Sin coste. Usar el servicio no carga coste directo sobre la factura.
Y yo para qué lo voy a usar?
La idea es usar AWS Organizations para luego posteriormente, aprovecharme de la integración con Security Hub. Y también para poder establecer políticas necesarias via las SCP.
Paso 1. Crear una cuenta nueva
Hemos de hacer todo el proceso manual de creación de nueva cuenta. Una vez hecho eso, activaremos el servicio de AWS Organizations.
Paso 2. Habilitar la organización en Terraform
resource "aws_organizations_organization" "this" {
aws_service_access_principals = [
"cloudtrail.amazonaws.com",
"config.amazonaws.com",
"sso.amazonaws.com",
"securityhub.amazonaws.com"
]
feature_set = "ALL"
}
Paso 3. Crear las OUs
resource "aws_organizations_organizational_unit" "security" {
name = "security"
parent_id = "${var.aws_id_root_account}"
}
resource "aws_organizations_organizational_unit" "production" {
name = "production"
parent_id = "${var.aws_id_root_account}"
}Paso 4. Añadir las cuentas a las OUs
resource "aws_organizations_account" "production" {
name = "A Name"
email = "random@domain.com"
parent_id = "${data.terraform_remote_state.state.organization_production_id}"
}
Paso 5. Opcional. Configurar cuenta delegada para Security Hub
Configurar una cuenta de nuestra organización como la delegada de seguridad nos permite centralizar en una sola cuenta, que será típicamente una cuenta dedicada solo a seguridad, la gestión de Security Hub. Desde esta cuenta se podrá invitar a otras como miembros.
Security Hub also recommends that the organization management account does not designate itself as the Security Hub administrator account.
The users who have access to the organization management account to manage billing are likely to be different from the users who need access to Security Hub for security management.
https://docs.aws.amazon.com/securityhub/latest/userguide/designate-orgs-admin-account.html
Paso 6. Crear las SCPs
Vamos a crear y a aplicar SCPs con Terraform en nuestra organización. Pero antes recuerda que:
SCPs don’t affect users or roles in the management account. They affect only the member accounts in your organization.
Paso 6.1 Limitar las regiones con AWS Organizations y Terraform
data "aws_iam_policy_document" "restrict_regions" {
statement {
sid = "RegionRestriction"
effect = "Deny"
actions = ["*"]
resources = ["*"]
condition {
test = "StringNotEquals"
variable = "aws:RequestedRegion"
values = [
"us-east-1",
"eu-west-1"
]
}
}
}
resource "aws_organizations_policy" "restrict_regions" {
name = "restrict_regions"
description = "Deny all regions except N.Virginia and Ireland"
content = "${data.aws_iam_policy_document.restrict_regions.json}"
}
resource "aws_organizations_policy_attachment" "restrict_regions_on_root" {
policy_id = "${aws_organizations_policy.restrict_regions.id}"
target_id = aws_organizations_organization.this.roots[0].id
}
Aplicamos esto y ….
ERROR !!!!
Habilitar SCP desde cuenta root
Me había dejado algo por el camino. Al aplicar el código de arriba nos va a devolver esto:
* aws_organizations_policy_attachment.restrict_regions_on_root: error creating Organizations Policy Attachment: PolicyTypeNotEnabledException: This operation can be performed only for enabled policy types.
El problema es que no hemos habilitado previamente la capacidad de las SCPs. Como se ve en la imagen.
Para hacerlo hay que añadir este pequeño código a la parte donde creamos la organización. Si hacemos el cambio a mano en la consola, Terraform deshará el cambio así que hay que ponerlo igualmente.
enabled_policy_types = [
"SERVICE_CONTROL_POLICY"
]Después de habilitarlo podemos ver de hecho que la policy que subimos antes si se creó.
aws_organizations_policy_attachment.restrict_regions_on_root: Creating...
policy_id: "" => "p-hug0hxf6"
target_id: "" => "r-123"
aws_organizations_policy_attachment.restrict_regions_on_root: Creation complete after 1s (ID: r-123:p-hug0hxf6)
Y listo, ya hemos creado y agregado una SCP a nuestra organización. En este caso, lo hemos asignado al OU Root que es el primario y por tanto, en cascada, se aplica al resto de OUs.
Paso 6.2 Limitar los tipos de instancia con AWS Organizations y Terraform
Estas pruebas se hacen en una cuenta que tiene muy pocos recursos. Entonces, es fácil listar que instancias estamos usando. Aunque pueda parecer innecesario, no lo ves.
Imaginemos que sufrimos una intrusión en la cuenta de producción. Un comportamiento posible podría ser levantar instancias muy grandes que tengan gran capacidad de computación y dedicarlas a fines como el minado de criptomonedas.
Un saludo desde aquí, crypobros.
Entonces, por qué no preveer eso? Y evitarlo? Aunque tengas una cuenta pequeña, la capacidad de hacer daño en el cloud es muy grande.
data "aws_iam_policy_document" "restrict_ec2_types" {
statement {
sid = "RestrictEc2Types"
effect = "Deny"
actions = ["ec2:RunInstances"]
resources = ["arn:aws:ec2:*:*:instance/*"]
condition {
test = "StringNotEquals"
variable = "ec2:InstanceType"
values = [
"t3.micro",
"t3.small"
]
}
}
}
resource "aws_organizations_policy" "restrict_ec2" {
name = "restrict_regions"
description = "Deny all types or EC2 that are not allowed"
content = "${data.aws_iam_policy_document.restrict_ec2_types.json}"
}
resource "aws_organizations_policy_attachment" "restrict_ec2_types" {
policy_id = "${aws_organizations_policy.restrict_ec2.id}"
target_id = "${var.aws_id_root_account}"
}Y de momento, ya he agregrado dos SCPs a mi árbol de cuentas.
Y por hoy ya se acabó.
