Passordpolicy
Brukere med tilgang til webgrensesnittet (CMC) vil automatisk f? varsel om ? skifte passord n?r det n?rmer seg et ?r siden sist. Vi oppfordrer brukere til ? samtidig rotere sine n?kkelpar, b?de systembrukerens hovedn?kkel og eventuelle opprettede IAM-n?kler.
Dette gj?res enkelt ved ? opprette et nytt n?kkelpar, og slette det forrige.
For r?de b?tter roterer vi rutinemessig n?klene tilh?rende systembrukere som eier b?ttene, men vi mangler system for rutinemessig rotering av IAM-n?klene som deles ut til sluttbruker.
Det vil komme en oppdatering her s? snart det lar seg gj?re.
Databeskyttelse
Vi har tre alternativer for databeskyttelse:
- Versjonering av objekter
- Tradisjonell backup til annet lagringssystem
- Replikering til separat Cloudian-instans
Versjonering betyr at systemet beholder samtlige kopier av objekter med samme navn (key), slik at man i praksis f?r en endringshistorikk per objekt. Dette beskytter b?de mot u?nskede overskrivelser, samt. sletting av filer. Dersom det kun finnes én versjon av et objekt, vil det dupliseres f?r det p?legges en slettemark?r p? gjeldende versjon.
Brukerne kan selv bestemme om hvorvidt det skal v?re automatisk sletting av tidligere versjoner, og hvor ofte dette skal gj?res. Dessuten blir det ingen overraskelser mtp. kostnad da den ekstra kapasiteten som benyttes av eldre versjoner g?r p? ordin?r kvote.
For mange kan dette v?re god nok databeskyttelse i seg selv, men merk at versjonering ikke kan anses som god nok beskyttelse i seg selv for s?rbare data som skal lagres over lang tid.
Tradisjonell backup lagrer en full kopi samt. inkrementelle endringer p? b?tten én gang i d?gnet, og har retensjonstid p? 90 dager. Dette kan v?re n?dvendig dersom man har kritiske data man vil ha kopi av p? separat system og datasenter.
P?bel?per en ekstra kostnad.
Til slutt har vi en separat, virtuell Cloudian-instans som kan benyttes for ? laste opp samme data til to separate steder. Denne instansen har derimot sv?rt begrenset kapasitet, og er en tjeneste vi kun tilbyr for de aller mest kritiske dataene.
Sikring av aksessn?kler p? klienten
Per default lagres konfigurerte n?kkelpar i klartekst under ~/.aws/credentials. I utgangspunktet er tilgangen til disse sperret ned til eieren av hjemmeomr?det, men det anbefales ? kryptere n?kkelfila slik at uvedkommede ikke ogs? f?r tilgang til objektlagringen dersom maskinen blir hacket. Dette er spesielt viktig dersom det lagres sensitive data i b?ttene.
I credentialsfila kan man i stedet for n?klene angi en parameter som vil peke p? et skript som henter dem ut
[default] region = oslo credential_process = /sti/til/skript
credential_process forventer en JSON-output p? f?lgende format:
{
"Version": 1,
"AccessKeyId": "AKIA0123456787EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}
P? denne m?ten kan vi opprette et skript som enten dekrypterer en kryptert n?kkelfil, eller henter ned n?kler fra f.eks Vault, Enpass, eller annet passordhvelv. Se under.
1. Kryptering + dekrypteringsskript
Denne metoden krever kun at man har et standard krypteringsverkt?y som OpenSSL, og et par linjer med shellkode. Derfor er det tilgjengelig ut av boksen p? de aller fleste Unix-systemer.
Start med ? opprette en JSON-fil med n?klene i formatet over, og krypter det med openssl med f?lgende opsjoner:
openssl enc -aes-256-cbc -md sha512 -pbkdf2 -in s3-creds.json -out s3-creds.enc
Du vil bli bedt om ? skrive inn et passord, som du m? ogs? m? tilf?ye n?r fila skal dekrypteres. Lagre gjerne dette i Vault e.l, slik du vanligvis oppbevarer delte passord.
Ekstra steg for Mac-brukere
Per default bruker MacOS LibreSSL for kryptering, som ikke supporterer pbkdf2-funksjonen i eksempelet over.
S? hvis du opplever at det feiler, sjekk versjonenav openssl. Hvis det refereres til LibreSSL, installer heller ordentlig OpenSSL (fra f.eks brew), og legg det til i din PATH:
# openssl version LibreSSL 3.3.6# brew update # brew install openssl #echo 'export PATH="/usr/local/opt/openssl@3/bin:$PATH"' >> ~/.bash_profile# openssl version OpenSSL 3.1.2 1 Aug 2023 (Library: OpenSSL 3.1.2 1 Aug 2023)
N? oppretter vi et kort dekrypteringsskript som skal pekes p? i credential_process, slik at den krypterte JSON-fila med n?klene kan dekrypteres ved behov.
I sin simpleste form kan det se slik ut:
#!/bin/sh openssl enc -d -aes-256-cbc -md sha512 -pbkdf2 -in $1 -pass env:S3_PW
Dekrypteringsskriptet over forventer en sti til kryptert fil n?r det kj?re (argument $1), og at passord p? forh?nd er satt som en environmentvariabel, S3_PW. Denne kan settes uten ? vise input i terminalen slik:
read -s -r S3_PW && export S3_PW
Merk at n?r du lukker terminalen, s? vil denne variabelen bli fjernet, og m? settes p? ny ved neste sesjon.
Til slutt, oppdatert ~/.aws/credentials til ? bruke dekrypteringsskriptet:
[default] region = oslo credential_process = /sti/til/decrypt.sh /stil/til/s3-creds.enc
N?r du n? fors?ker ? utf?re et S3-kall mot lagringen via denne konfigurerte profilen, vil skriptet automatisk dekryptere s3-creds.enc og autorisere med de assosierte n?klene.
Husk ? fjerne den ukryptere fila n?r det er bekreftet at oppsettet fungerer.
2. Uthenting av credentials fra passordhvelv
Guiden under tar utgangspunkt i HashiCorp Vault (som er mye brukt internt), men de fleste passordhvelv/managers har tilsvarende API'er som kan benyttes for ? hente ut lagrede hemmeligheter.
For ? bruke denne metoden trenger du ? ha Vault-klienten installert. Start med ? legge en hemmelighet p? samme JSON-format p? en foretrukket sti i passordhvelvet slik:P? en foretrukket sti i tjenesten, lag en hemmelighet p? f?lgende format In your prefered path, create the credential like this, where the name "system_user_testbucket" is the name of the key where you will be storing the JSON-data containing your access key and secret key.
vault kv put /secret/engine/sti/til/S3_credentials testbruker='{
"Version": 1,
"AccessKeyId": "AKIA0123456787EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}'
S? kan vi lage et bashskript som henter ut n?klene slik:
#!/bin/bash
vault kv get --field $1 /secret/engine/sti/til/S3_credentials
N?r skriptet kj?res m? du angi hvilken bruker du skal hente ut credentials fra, i eksempelet over = testbruker. Det vil si at du kan lagre flere brukere i samme hemmelighet, og dynamisk hente ut det du trenger slik:
$ ./retrieve_S3_vault.sh testbruker
{
"Version": 1,
"AccessKeyId": "AKIA0123456787EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}
N?r det er bekreftet ? fungere, oppdatert .aws/credentials:
[default]
region = oslo
credential_process = /sti/til/retrieve_S3_vault.sh testbruker
Merk at hver gang du skal kommunisere med buckets m? du f?rst logge inn til Vault CLI i forkant for ? ha en gyldig token (som vanligvis ekspirerer etter 1 time).
Server Side Encryption (SSE)
UiO S3-l?sningen supporterer SSE, som i praksis betyr at dataene er kryptert p? lagringen ("at rest"). Dette beskytter dataene dersom uvedkommede skulle f? fysisk adgang til serverne.
Ulempen med SSE er at dataene dekrypteres ved requests, ogs? om b?tten ved uhell har blitt gjort public. P? sikt ?nsker vi ? sette opp st?tte for KMS-kryptering som ogs? h?ndterer dette issuet, men i mellomtiden kan man benytte en krypteringsn?kkel n?r data lastes opp for ? unng? at sensitive data lekkes ved uhell. Dette kalles SSE-C (Server Side Encryption with Customer key).
Merk at n?r et objekt lastes opp med SSE-C benyttes det en krypteringsn?kkel, m? samme n?kkel benyttes for nedlasting senere. Dette medf?rer en viss risiko;
hvis krypteringsn?kkele g?r tapt, er objektet ogs? i praksis tapt.
For mer info referer vi til Amazons guide om SSE-C med PowerShell, men det vil bli skrevet eksempler som tar i bruk AWS CLI.
Vi mener imidlertid at alle former for kryptering "at rest" kan gi en form for falsk sikkerhet, da det ikke erstatter god h?ndtering av IAM-n?kler og eventuelle b?ttepolicier, som i seg selv tilbyr vel s? god beskyttelse fra brukersiden.