Skip to main content
Gå til innhold

Core principles for running services on AWS

Grunnprinsipper for bruk av AWS i Sikt

note

"If you own the application, you own the security as well"

"Attention to detail"​

It doesnt need to be perfect ("Perfect is the enemy of good"), but we must understand how it works before we deploy to production.

“We run a tight ship”​

Økende grad av struktur og tilgangsbegrensning fra utviklings-faser til produksjon.

From chaos to order (sandbox - dev - [test - staging] - prod):​

From chaos to order

Secure by default​

Komponenter skal regelmessig sjekkes for sårbare og utdaterte komponenter. Denne kontrollen bør foregå både før komponenter rulles ut (i git og/eller i byggeprosessen), og regelmessig mens komponenten er i prod:

  1. ECS (Bruk AWS sin egen tjeneste: https://aws.amazon.com/about-aws/whats-new/2019/10/announcing-image-scanning-for-amazon-ecr/)
  2. Lambda (bruk feks Dependabot hos GitHub)
  3. EC2: Inspector, Systems Manager (Agent + Inventory + Compliance)

Infrastructure as Code​

caution

"If your AWS setup was created by clicking around in the web based management console you are managing infrastructure manually. The biggest problem with this approach: it is not reproducible, it is not documented and you can make a lot of mistakes."

  • Bruk CloudFormation i dev/prod. Bruk sandbox-kontoer for manuell eksperimentering i AWS web-console/CLI/API.
  • Deklarer så mye som mulig av ressursene i CloudFormation templates. Vær forsiktig med dynamisk generering av ressurser direkte fra applikasjonskode, spesielt i prod. Det gjør det vanskeligere å kjøre arkitektur-review i utviklingsprosessen, samt at koden som skal opprette de respektive ressursene må tildeles vide rettigheter. Med API kan man gjøre mye gøy dynamisk i prod, men forsøk så langt det er mulig å gjøre dette direkte i CloudFormation templates. Med ressurser her menes EC2-instanser, databaser, ApiGateways, ES/ECS cluster etc. S3 buckets bør også deklareres i templates.

EC2​

  • Ikke åpne port 22: Bruk SSM Session Manager! All SSH/terminaltilgang til EC2-instanser skal gjøres via SSM session Manager. Direkte SSH-tilgang med nøkler eller passord omgår AWS IAM, og er dermed ikke ønskelig. 2 opsjoner for terminal-tilgang:
    1. (Uten SSH) SSM Session Manager start session
      • Direkte i AWS Web console
      • CLI: aws ssm start-session --target i-[instance-number]
    2. (SSH) SSM Session Manager AWS-StartSSHSession
      • m/SSH public key som er lagt inn i ~/.ssh/authorized_keys i EC2-instansen
      • m/temporær SSH-nøkkel (aws ec2-instance-connect send-ssh-public-key)
  • I utgangspunktet ønskes det at man benytter operativsystemet Amazon Linux 2.

Føderering​

  • All tilgang til management plane (WebConsole, CLI, API) skal skje via føderert pålogging med Feide. AWS IAM Users skal ikke benyttes.
  • Man bør benytte føderering/IAM Roles så langt det lar seg gjøre. Her er eksempel på hvordan man kan integrere en ekstern tjeneste (GitHub/Gitlab) via føderering: https://unit.atlassian.net/wiki/spaces/AWS/pages/2069790732
  • Andre alternativ er: IAM Roles Anywhere (Private CA/PKI), eller la Vault utstede temporære Role credentials. Platon kan på forespørsel opprette IAM Users/Roles ved behov for eksterne integrasjoner (feks ekstern Jenkins)
  • Web-console via: https://aws.sikt.no
  • Terminal (CLI/API) via: samlauth.py

AWS Region​

  • Det er ønskelig at man benytter regioner som ligger i nærhet til Norge, forholdsvis:
    1. eu-west-1 (Ireland - Dublin)
    2. eu-north-1 (Stockholm)
  • Noen globale ressurser ligger kun i us-east-1 (N.Virginia). Behov for andre regioner, ev. multi-region kan diskuteres med Plattformteamet (Platon).

Public facing services​

  • All trafikk fra internett mot våre tjenester i AWS bør gå via en AWS managed service, feks ApiGateway, CloudFront eller Application Load Balancer. Disse tjenestene tilbyr bl.a. sertifikathåndtering og TLS, automatisk redirigering fra HTTP til HTTPS, lagring av tilgangslogger, og har i tillegg støtte for integrasjon mot AWS Shield og WAF, som gir basis DDOS-beskyttelse (Shield) og beskyttelse mot enkelte webapplikasjonssårbarheter (WAF).
  • All kommunikasjon over internett skal benytte transportsikring, feks TLS for HTTP.
  • Kun “standard”-porter (80/443) bør gjøres tilgjengelig på internett.

Utviklingsmiljø​

  • Utviklingsmiljøene skal som utgangspunkt ikke være tilgjengelig for hele internett. Det er viktig å ikke eksponere halvferdige og usikre applikasjoner.
  • Dersom det er behov for at eksterne skal kunne teste nye versjoner, bør dette gjøres i en egen test/demo-konto.
  • Eksterne utviklere/konsulenter bør benytte VPN mot Sikt

Sikkerhet​

Integrasjoner mellom AWS-kontoer eller med eksterne tjenester og verktøy skal avklares med plattformteamet (Platon) på forhånd. Dette gjelder særlig integrasjoner som tildeler IAM-rettigheter.

Sletting av ressurser (S3-buckets, domenenavn)​

caution

”Bucket names are unique. If you delete a bucket, another AWS user can use the name.”

Når man ikke lenger har behov for en ressurs er det vanlig å slette ressursen. Men vær ekstra obs på f.eks. domenenavn som ikke eies av Sikt, feks *.cloud, og navn på S3-buckets. Ved å slette disse ressursene blir de tilgjengelig for andre. Har man pekere til disse ressursene, eller det kan tenkes at eksterne forventer å finne Sikt-innhold på slike lenker, så kan dette utgjøre en sikkerhetsrisiko. Tomme S3-buckets koster ingenting, så disse bør man vurdere å beholde en stund dersom de har vært brukt eksternt. Domenenavn som ikke faller inn under *.unit.no eller *.sikt.no kan koste noe, men det anbefales å beholde navnet en stund etter at det er faset ut.

Anbefalinger​

Før prod-setting: sjekk ut AWS Well architected Tool