Magento encryptiesleutel en env.php: secrets beheren

In app/etc/env.php staat de sleutel van je hele shop. Wie dat bestand heeft, heeft je databasewachtwoord, je encryptiesleutel en vaak ook je cache- en sessiegegevens.

Toch zien we dat bestand regelmatig in git, in een Slack-bericht of in een zip op een gedeelde schijf. Dit artikel legt uit wat erin staat, wat je ermee beschermt en hoe je veilig roteert.

Wat staat er in env.php?

• crypt/key: de encryptiesleutel van Magento;
• db: host, naam, gebruiker en wachtwoord van de database;
• backend/frontName: het pad van je admin;
• session, cache: verbindingsgegevens voor Redis of files;
• install/date en andere installatiegegevens;
• soms API-sleutels, SMTP-gegevens of integratiegegevens die door een ontwikkelaar "even snel" zijn toegevoegd.

Het tegenstuk is app/etc/config.php. Dat bevat de lijst met modules en de gedeelde configuratie en hoort wel in git. Het scheiden van die twee is de kern van veilig secrets-beheer in Magento.

Wat doet de encryptiesleutel?

De crypt/key wordt gebruikt om gevoelige waarden in de database te versleutelen. Denk aan:

• wachtwoorden of API-sleutels van betaalmethoden en verzendkoppelingen, zoals ze in core_config_data staan;
• SMTP-wachtwoorden;
• andere waarden die in de admin als "encrypted" worden opgeslagen.

Belangrijk om te begrijpen: de sleutel zelf zit niet in de database, de versleutelde data wel. Een aanvaller met alleen een database-dump kan die waarden dus niet direct lezen. Een aanvaller met database én env.php wel.

Dat maakt env.php een extra waardevol doelwit. Veel skimmers en backdoors gaan er expliciet naar op zoek.

Klantwachtwoorden zijn een ander verhaal: die worden gehasht, niet versleuteld met deze sleutel. Een gelekte sleutel maakt klantwachtwoorden dus niet direct leesbaar.

Wat hoort niet in git

Zet in je repository nooit:

• app/etc/env.php;
• .env-bestanden met productiewachtwoorden;
• database-dumps van productie;
• SSH-keys, auth.json met repo.magento.com-sleutels of andere tokens;
• back-ups in een map in de repo.

Is dit eenmaal gebeurd? Dan is verwijderen uit de laatste commit niet genoeg. De geschiedenis bevat het nog. Beschouw de secrets dan als gelekt en vervang ze. Het opschonen van de git-geschiedenis kan, maar ga uit van het slechtste: zodra het ooit in een gedeelde of publieke repo stond, kan iemand het hebben gekopieerd.

Een goede .gitignore voorkomt het meeste:

/app/etc/env.php
/auth.json
/var/
/generated/
/pub/media/
/pub/static/
*.sql
*.sql.gz

Voeg daarbovenop een secrets-scanner toe aan je CI of pre-commit hook. Meer daarover in ons artikel over veilig bouwen met een klein team.

Hoe beheer je secrets per omgeving?

Er zijn grofweg drie niveaus, afhankelijk van de grootte van je setup.

Niveau 1: env.php per server

Het bestand wordt één keer op de server aangemaakt en bij deploys niet overschreven. Dit is de meest voorkomende en prima voor een enkele productieserver. Zorg dat:

• alleen de deploy- en PHP-gebruiker het kunnen lezen (geen wereld-leesbare rechten);
• de deploy het bestand niet vervangt;
• je een versleutelde kopie in een wachtwoordmanager hebt voor herstel.

Niveau 2: Magento-configuratie vergrendelen

Magento kan configuratie via de CLI in env.php of config.php vastleggen, zodat de waarde niet meer in de admin kan worden aangepast. Voor gevoelige waarden bestaat een commando als bin/magento config:sensitive:set, dat een waarde in env.php zet in plaats van in de database. Controleer in de documentatie van jouw Magento-versie de exacte syntax en wat er ondersteund wordt, voordat je het gebruikt.

Voordeel: een SQL-injectie of database-dump levert die waarde niet meer op.

Niveau 3: omgevingsvariabelen en een secrets-manager

Bij meerdere servers, containers of pipelines is het beter om secrets uit een secrets-manager te halen en tijdens de deploy in env.php te schrijven of via omgevingsvariabelen aan te leveren. Dan staat het geheim nooit in de repo en is rotatie een kwestie van één plek aanpassen.

Dit is overkill voor een kleine shop op één server. Het wordt zinvol zodra meerdere mensen of systemen secrets nodig hebben.

Deploy-secrets in je pipeline

Een pipeline heeft vaak meer macht dan een mens: hij kan naar productie schrijven. Dat maakt hem een mooi doelwit. Houd rekening met:

• secrets staan als beschermde variabelen in je CI, niet in de pipeline-code;
• logging van de pipeline toont geen secrets;
• auth.json voor repo.magento.com is een eigen sleutel met een eigen eigenaar. Gebruik per project of organisatie een eigen sleutelpaar en trek ze in als iemand vertrekt;
• de deploy-user op de server heeft niet meer rechten dan nodig.

Zie ook ons artikel over software supply chain en CI.

Wanneer moet je de encryptiesleutel roteren?

Niet "elk kwartaal omdat het kan". Roteren van de crypt/key is een ingreep met risico, zoals hieronder. Er zijn wel duidelijke momenten:

Bij een hack is de volgorde belangrijk: eerst de aanvaller eruit, dan pas roteren. Roteer je terwijl hij nog toegang heeft, dan pakt hij de nieuwe sleutel ook. Het hele draaiboek staat in Magento 2 gehackt: wat nu?.

Hoe roteer je veilig?

Magento heeft in de admin een functie om de encryptiesleutel te wijzigen (onder het beheergedeelte voor tools). Die genereert een nieuwe sleutel en versleutelt de bekende gevoelige waarden opnieuw. Maar er zitten haken en ogen aan:

1. Maak eerst een volledige back-up van database en env.php. Zonder terugweg begin je er niet aan.
2. Test op staging met een recente kopie van productie.
3. Niet alles wordt automatisch opnieuw versleuteld. Waarden die een extensie op een eigen manier opslaat, of die buiten de standaard-configuratie staan, kunnen onleesbaar worden. Denk aan betaalprovider-modules met eigen opslag.
4. Check alle betaalmethoden en koppelingen na de wissel. Een foutieve decryptie van een betaalsleutel merk je pas als een betaling faalt.
5. Plan buiten piekuren en zet zo nodig de shop kort in maintenance mode.
6. Roteer ook de andere secrets: databasewachtwoord, admin-wachtwoorden, integratietokens, API-sleutels van derden, Redis-wachtwoord. Een nieuwe encryptiesleutel helpt weinig als het databasewachtwoord hetzelfde blijft.
7. Verwijder de oude sleutel uit alle plekken waar hij is opgeslagen, inclusief back-ups waar je dat redelijkerwijs kunt.

Ons advies: laat dit doen door iemand die het eerder heeft gedaan. Het is geen moeilijke ingreep, maar fouten zijn pijnlijk en niet altijd direct zichtbaar. Heb je de functie nodig maar twijfel je over de uitwerking? Test, test en test nog eens op staging.

Veelgemaakte fouten

• env.php in de repo "voor het gemak". Daarna zit het in elke clone, elke fork en elke back-up.
• Dezelfde sleutel op staging en productie. Staging is vaak minder goed beschermd en bevat soms productiedata.
• Productiedatabase op een laptop. Een gestolen laptop is dan een datalek.
• Geen overzicht van wie wat weet. Bij een incident weet je dan niet wat je moet vervangen.
• Roteren zonder back-up.
• Rechten van env.php op 644 of ruimer op een gedeelde server.

Een datalek waarbij persoonsgegevens betrokken zijn, moet je binnen 72 uur melden bij de Autoriteit Persoonsgegevens als er risico is voor betrokkenen. Lees hoe dat werkt.

Checklist secrets

• [ ] env.php staat niet in git
• [ ] Rechten op env.php beperkt tot de gebruikers die het nodig hebben
• [ ] Staging en productie hebben verschillende sleutels en wachtwoorden
• [ ] Gevoelige configuratiewaarden zijn niet onnodig in de database opgeslagen
• [ ] CI-secrets staan als beschermde variabelen
• [ ] auth.json en deploy-keys hebben een eigenaar en een intrekprocedure
• [ ] Er is een versleutelde kopie van env.php voor herstel
• [ ] Rotatie is een gedocumenteerd, geteste procedure
• [ ] Na elk incident of vertrek: secrets-review

Veelgestelde vragen

Wat gebeurt er als ik de encryptiesleutel kwijtraak?

Versleutelde waarden in de database kunnen dan niet meer worden gelezen. Je moet ze opnieuw invoeren, bijvoorbeeld betaalsleutels en SMTP-wachtwoorden. Daarom bewaar je een versleutelde kopie van env.php in een wachtwoordmanager of kluis.

Zijn klantwachtwoorden versleuteld met de crypt key?

Nee. Klantwachtwoorden worden gehasht, niet met deze sleutel versleuteld. Een gelekte sleutel geeft dus geen directe toegang tot klantwachtwoorden, maar wel tot de versleutelde configuratiewaarden zoals betaal- en mailgegevens.

Moet ik na een hack altijd de sleutel roteren?

Als de aanvaller bestandstoegang had, ga er dan van uit dat env.php is gelezen en roteer. Doe dat nadat de toegang is dichtgezet en de malware is verwijderd. Zie het stappenplan na een hack.

Kan ik secrets in omgevingsvariabelen zetten in plaats van env.php?

Ja, voor bepaalde configuratie ondersteunt Magento dat. Het is vooral zinvol bij meerdere servers of containers. Controleer per instelling of dit werkt in jouw versie, en test op staging.

Is dit ook relevant voor Laravel of Shopify?

Het principe wel: secrets buiten de repo en roteren na een incident. Laravel gebruikt een .env met APP_KEY, wat grotendeels dezelfde discipline vraagt. Zie onze Laravel security checklist.

Twijfel je of jouw env.php en deploy-flow op orde zijn? Wij kijken mee binnen een Magento security audit of regelen het vast via Magento support. Je krijgt direct antwoord van degene die het uitvoert. Neem contact op via /contact.