Skip to main content
Gå til innhold

Core principles for running services on AWS

note

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

Infrastructure as Code​

CloudFormation and Terraform are the recommended Infrastructure as Code (IaC) tools for automating the provisioning, management, and configuration of Platon infrastructure. If you choose to use alternative tools, your team will be solely responsible for maintaining the necessary expertise in that technology. Please note that Platon may not be able to provide assistance with tools outside the recommended options.

caution

If your AWS setup was created by manually clicking through the web-based management console, you are managing infrastructure manually. The main drawbacks of this approach are lack of reproducibility, insufficient documentation, and a higher risk of errors.

Any manual experimentation and resource creation in the AWS Web Console should be restricted to dev & sandbox accounts only.

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 OS som Platon støtter. De bør også rulles inn i Puppet for konfigurasjonsstyring.

Føderering​

  • All tilgang til management plane (WebConsole, CLI, API) skal skje via føderert pålogging med AWS Identity Center. 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)

AWS Region​

  • Det er ønskelig at man benytter regioner som ligger i nærhet til Norge, forholdsvis:
    1. eu-north-1 (Stockholm)
    2. eu-west-1 (Ireland - Dublin)
  • 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.