Auditlogboeken deel 2: Vergelijking van logboekfuncties in webservices

AWS, Cloudflare, Vercel, Supabase, headless CMS: wat blijft over?

Hallo, ik ben Otsuka, CTO bij Liberogic.

We hebben eerder de verschillen tussen toegangslogboeken, toepassingslogboeken en auditlogboeken uitgewerkt.

Deze keer kijken we gedetailleerder naar welke soorten logboeken beschikbaar zijn in de services die we dagelijks gebruiken: AWS, Cloudflare, Vercel, Supabase en headless CMS.

Dit gaat niet om een gedetailleerde vergelijking van prijzen en functies per service.

De kenmerken verschillen aanzienlijk tussen services: wat standaard beschikbaar is en hoe ver je achteraf kunt teruggaan. We geven hier een ruw overzicht.

Zelfs met dezelfde "logfunctie" kunnen de doelbewerkingen en opslagperiodes verschillen.

Daarnaast is het verschil tussen wat wordt weergegeven in het beheerscherm en wat langdurig voor audit wordt opgeslagen een ander verhaal.

AWS heeft alles, maar configuratie is nodig

AWS biedt uitgebreide logservices.

Bijvoorbeeld worden de executiestatussen van Lambda en API Gateway verzameld in CloudWatch Logs. Acties die in de AWS-beheerconsole of via API worden uitgevoerd, kunnen worden geregistreerd in CloudTrail.

Kort gezegd:

• CloudWatch Logs: zien hoe applicaties en AWS-services werken
• CloudTrail: zien wie wat deed in uw AWS-omgeving
• S3: logboeken langdurig opslaan

is de rolverdeling.

Omdat zoeken, bewaking, meldingen en langdurige opslag allemaal binnen AWS kunnen worden georganiseerd, is dit een configuratie die gemakkelijk voldoet aan systemen met sterke auditverplichtingen.

Echter, 'omdat u AWS gebruikt, blijven alle dingen automatisch behouden' is niet noodzakelijk het geval.

U moet logboekuitvoer per gebruikte service configureren en ook beslissen over bewaartermijnen en opslaglocaties. Vanwege de hoge mate van flexibiliteit is het essentieel om dit goed te ontwerpen.

Cloudflare scheidt korte termijnonderzoeken en externe opslag

In Cloudflare Workers kunt u de output en fouten die met console.log() zijn weergegeven, controleren in Workers Logs.

Het is erg handig voor verificatie tijdens ontwikkeling en onderzoek naar recente storingen, maar bij het bijhouden van controletrails over langere perioden is het beter om niet alleen afhankelijk te zijn van het standaard logscherm.

Voor logbestanden die langdurig moeten worden bewaard, kunt u een configuratie overwegen waarbij u Logpush of vergelijkbare tools gebruikt om gegevens naar R2 of externe logbeheersingsservices te sturen.

Wanneer u statische websites distribueert via Cloudflare Pages of Workers, worden niet alle toegang geregistreerd in de uitvoeringslogboeken van Workers.

De site werkt normaal, dus u zou kunnen denken dat 'natuurlijk ook logbestanden van toegang aanwezig zijn', maar de distributie van statische bestanden en de uitvoering van Workers zijn verschillende processen.

Hoewel Cloudflare relatief compacte configuraties gemakkelijk maakt, moet u begrijpen welke verwerking waar doorheen gaat om logbestanden juist in te richten.

Vercel maakt het eenvoudig om Next.js-logbestanden te controleren

In Vercel kunt u logbestanden van Next.js Functions en Server Actions controleren via het beheerdersdashboard.

Omdat implementatie en uitvoeringslogbestanden dicht bij elkaar liggen, is dit voor ontwikkelaars duidelijk en kunnen fouten gemakkelijk worden onderzocht.

De periode waarin logbestanden kunnen worden bekeken en het bereik van externe overdracht verschillen echter per plan.

Wanneer u logbestanden gedurende lange tijd wilt bewaren, hebt u aanvullende mechanismen nodig, zoals het gebruik van Drains om gegevens naar externe opslaglocaties te sturen.

Niet alleen bij Vercel geldt dat logs in het beheerdashboard worden weergegeven iets anders is dan dat ze voor audit doeleinden lang worden bewaard.

Deze twee zaken moeten afzonderlijk worden gecontroleerd.

Supabase heeft veel logs buiten de database

Supabase is een service gebaseerd op PostgreSQL, maar bestaat in feite uit meerdere functies: naast de database ook authenticatie, API, opslag en Edge Functions.

Omdat elk van deze logs in het beheerdashboard kan worden gecontroleerd, is het makkelijk om de werking van de gehele applicatie te volgen.

Daarnaast zijn er ook logs voor authenticatie en audit logs om bewerkingen in het Supabase beheerdashboard te controleren.

Hier moet je echter ook oppassen: beheerbewerkingen in Supabase zijn iets anders dan bewerkingen in de applicatie die je zelf hebt gemaakt.

Bijvoorbeeld: hoewel de Supabase service kan bijhouden "wie de projectinstellingen heeft gewijzigd", moet aan de toepassingskant worden geregistreerd "wie klantengegevens in ons beheerdashboard heeft gewijzigd".

Controleer ook de operatiegeschiedenis van headless CMS

Headless CMS-en zoals microCMS, Kuroco en NILTO bieden updategeschiedenis van inhoud en bewerkingslogs van het beheerdashboard.

Registraties van wie een artikel heeft bijgewerkt, wanneer het is gepubliceerd, en welke instellingen of machtigingen zijn gewijzigd, zijn belangrijk als auditlogboeken voor websitebeheer.

De geregistreerde bewerkingen, de periode waarover deze kunnen worden gecontroleerd en de beschikbare plannen verschillen echter per service.

Zelfs als u de updategeschiedenis van inhoud kunt controleren, betekent dit niet dat alle beheerwerkzaamheden als auditlogboeken worden vastgelegd.

Bovendien bevat een CMS in principe alleen bewerkingsrecords uit de CMS zelf. Toegang tot de gepubliceerde website en fouten die zich op de frontend voordoen, moeten worden gecontroleerd aan de zijde van de hostingomgeving.

Bij headless CMS-projecten is het gemakkelijker om het CMS, frontend, hosting en API als één systeem te beschouwen.

Bij toevoeging van Datadog of Sentry

Wanneer logboeken over meerdere services zijn verspreid, moet u telkens wanneer er een storing optreedt elk beheerscherm openen om onderzoek in te stellen.

Door logboeken naar een logboekbeheerservice zoals Datadog te consolideren, kunt u logboeken van meerdere omgevingen gezamenlijk doorzoeken en afwijkingen detecteren en meldingen ontvangen.

Sentry wordt ook veelvuldig gebruikt, maar deze service is goed in het onderzoeken van waar fouten zich voordoen en hun impact.

Beide zijn nuttig, maar implementatie leidt niet automatisch tot een volledig auditlogboek.

U moet aan de kant van de applicatie bepalen wat u wilt uitvoeren, en als u alle logs gedurende lange tijd opslaat, nemen de kosten toe naarmate de gegevensomvang groeit.

In de praktijk is het zinvol om onderscheid te maken tussen logs die je regelmatig raadpleegt en logs die je voor zekerheid bewaart.

Welke service het beste is, kan je niet zomaar bepalen

Je kunt niet alleen logs vergelijken en zeggen dat AWS het beste is of Cloudflare het beste is.

Wat belangrijk is, is wat je in een bepaald project moet vastleggen.

• Serviceproblemen onderzoeken
• Beheerdersacties bijhouden
• CMS-updatehistorie controleren
• Authenticatie en machtigingswijzigingen volgen
• Lange termijnopslag voor audittrails

Zodra je weet wat je nodig hebt, worden de onderdelen duidelijk die je kunt realiseren met standaardfuncties van elke service, en de onderdelen waar je extra uitwerkingen voor nodig hebt.

We stellen niet vanaf het begin een groot logregistratiesysteem in, maar passen de configuratie aan op basis van projectvereisten en budget.

De volgende keer zullen we bespreken welke loggegevens vanuit de applicatie worden gegenereerd en waar deze worden opgeslagen wanneer je dergelijke services combineert. We zullen ons meer richten op praktische implementatie.

Tot ziens.