Beveiliging en toegang

Beveiligd werken met je bedrijfsgegevens.

Je dashboard of webapp bevat informatie waarop je bedrijf draait. We nemen beveiliging daarom mee in het ontwerp, de bouw en het beheer: van wachtwoordopslag en tweestapsverificatie tot de rechten waarmee je team kan werken.

01 · Een eigen toegang

Een herkenbaar inlogvenster, met controles achter de schermen.

Voor een besloten werkomgeving richten we persoonlijke toegang in. De applicatie controleert je gegevens op de server voordat je bij dossiers, rapportages of acties kunt. Een verborgen pagina of een moeilijk te raden webadres is daarvoor onvoldoende.

De beelden laten in een neutrale voorbeeldomgeving zien hoe inloggen en een extra verificatiestap eruit kunnen zien. Bij Olympus Bouw worden wachtwoorden met scrypt gehasht. De toegang werkt met een beveiligde sessie, een vervaltijd en een limiet op inlogpogingen.

Voor jouw toepassing spreken we af wie toegang krijgt, welke extra controle nodig is en hoe accounts worden beheerd. Tweestapsverificatie met Google Authenticator kan onderdeel zijn van die inrichting.

02 · Wachtwoordopslag

Een wachtwoord controleren zonder het terug te kunnen lezen.

Met ‘versleutelde wachtwoorden’ wordt vaak bedoeld dat wachtwoorden veilig worden bewaard. Voor inlogwachtwoorden gebruiken we hashing: een eenrichtingsbewerking die van je wachtwoord een controlewaarde maakt. Bij het inloggen wordt je invoer daarmee vergeleken.

Een unieke toevoeging per wachtwoord, de salt, voorkomt dat dezelfde wachtwoorden automatisch dezelfde opgeslagen waarde opleveren. We kiezen hiervoor een wachtwoordfunctie zoals scrypt, Argon2id of PBKDF2, passend bij de toepassing.

Het oorspronkelijke wachtwoord hoeft daardoor niet leesbaar in de opslag te staan. Een beheerder hoeft het ook niet te kennen. Als je geen toegang meer hebt, richten we een herstelprocedure in waarmee je een nieuw wachtwoord kiest.

03 · Tweestapsverificatie

Een wachtwoord én een code op je telefoon.

Google Authenticator maakt een tijdelijke code voor een gekoppeld account. Bij de TOTP-inrichting die we hiervoor gebruiken, bestaat die uit zes cijfers en wordt de code elke 30 seconden vernieuwd. Bij een toepassing met tweestapsverificatie gebruik je naast je wachtwoord ook die code. In onze maatwerkoplossingen kunnen we deze extra stap inrichten voor gebruikers of specifieke rollen.

De app kan codes ook zonder internet maken. Je voegt het account eenmalig toe met een QR-code of instelsleutel uit de applicatie. Je vult vervolgens een code in om de koppeling te bevestigen.

Op deze screenshots zie je de officiële Google-app met voorbeeldaccounts. De concrete koppeling en herstelroute leggen we per omgeving vast. Google Authenticator is een product van Google; de extra stap wordt door de betreffende applicatie gecontroleerd.

De uitleg van Google over Authenticator ↗

Zo nemen we tweestapsverificatie in gebruik

  1. Persoonlijk koppelen

    We bepalen wie de extra controle nodig heeft. De gebruiker installeert een authenticatorapp en koppelt het eigen account in de daarvoor ingerichte omgeving.

  2. Inloggen en bevestigen

    De gebruiker voert het wachtwoord en de actuele code in. De server controleert beide voordat de werkplek beschikbaar komt. Een verlopen code geeft geen toegang.

  3. Herstel voorbereiden

    We spreken af hoe toegang wordt hersteld bij een nieuwe of verloren telefoon. Waar de toepassing dit ondersteunt, richten we herstelcodes of gecontroleerd herstel via een beheerder in.

Download de officiële app via Google Play ↗ of de App Store ↗.

04 · Rechten en gegevens

Toegang die past bij het werk van je team.

Een medewerker die een planning verwerkt, heeft andere mogelijkheden nodig dan iemand die gebruikers beheert of financiële gegevens beoordeelt. We brengen die verschillen vooraf in kaart.

Persoonlijke accounts en rollen

We bepalen wie informatie mag bekijken, aanpassen, exporteren of goedkeuren. Rechten horen op de server te worden gecontroleerd. Alleen een knop verbergen geeft onvoldoende bescherming.

Beveiligde sessies

Na het inloggen gebruik je een sessie met een afgesproken geldigheidsduur. Voor webapps richten we waar passend Secure- en HttpOnly-cookies in. Ook uitloggen en het beëindigen van toegang horen bij de inrichting.

Koppelingen met beperkte toegang

API-sleutels en tokens horen bij de serverconfiguratie en worden afgeschermd van de openbare website. We beperken hun rechten tot wat de koppeling nodig heeft en spreken af hoe intrekken en vervangen werkt. Lees hoe we systemen koppelen.

Gegevens met een duidelijke bestemming

We bekijken welke informatie nodig is, waar die wordt opgeslagen en wie ermee werkt. Bij AI-verwerking spreken we vooraf af welke gegevens naar welke leverancier gaan. Meer hierover staat in onze privacyverklaring.

05 · Beheer en continuïteit

Ook geregeld wanneer er iets verandert.

Een nieuwe medewerker, een verloren telefoon of een update van een leverancier: beveiliging vraagt om afspraken die in het dagelijkse werk bruikbaar blijven.

Medewerkers komen en gaan

We leggen vast wie accounts aanmaakt, rechten wijzigt en toegang intrekt. Bij uitdiensttreding of een andere functie moeten accounts, sessies en eventueel gedeelde koppelingen opnieuw worden beoordeeld.

Updates en technische controles

Bij beheerde omgevingen maken we afspraken over onderhoud, updates en controles op de bereikbaarheid. We stemmen af wie meldingen ontvangt, wie ingrijpt en welke ondersteuning bij jouw oplossing hoort.

Back-ups en herstel

We bepalen samen wat een back-up moet bevatten, hoe vaak deze nodig is, waar hij wordt bewaard en hoe herstel wordt getest. Dat stemmen we af op de gevolgen van gegevensverlies en uitval voor je bedrijf.

Registratie en opvolging

We kiezen welke gebeurtenissen nodig zijn voor controle en onderzoek, zonder wachtwoorden of geheime instelsleutels in logbestanden op te nemen. Bij bijzonderheden moet duidelijk zijn wie het onderzoekt en welke actie volgt. Meer over logging en monitoring.

Van afspraak naar een geteste inrichting.

  1. Inventariseren

    We bekijken de gegevens, gebruikers, koppelingen en dagelijkse handelingen. Daarna leggen we de benodigde maatregelen en verantwoordelijkheden vast.

  2. Bouwen en controleren

    We testen geldige en ongeldige aanmeldingen, rechten, sessieverloop en de afgesproken herstelroute. Bij wijzigingen controleren we opnieuw de betrokken toegang.

  3. Uitleggen en overdragen

    Je krijgt uitleg over accounts, inloggen en herstel. We spreken af wie het beheer uitvoert en hoe beveiliging wordt meegenomen bij verdere uitbreiding.

De maatregelen en het beheer worden per opdracht vastgelegd. De voorbeelden op deze pagina laten mogelijkheden en concrete onderdelen van onze aanpak zien.

Vragen over veilig werken

Is Google Authenticator al in iedere applicatie aanwezig?

We stemmen tweestapsverificatie af op de toepassing en de gebruikers. De neutrale voorbeeldschermen tonen de twee stappen. Bij de inrichting leggen we vast welke extra verificatie jouw omgeving krijgt; hiermee doen we geen toezegging dat iedere bestaande applicatie deze functie al heeft.

Kunnen jullie een vergeten wachtwoord terugsturen?

Een correct gehasht wachtwoord is niet terug te lezen. Daarom gebruiken we een procedure om een nieuw wachtwoord in te stellen, met controle van de identiteit van de gebruiker.

Wat gebeurt er als een telefoon zoekraakt?

Gebruik de vooraf afgesproken herstelroute en meld het bij de beheerder. Die beoordeelt de identiteit en de benodigde vervolgstappen, zoals sessies beëindigen en de authenticator opnieuw koppelen. Bewaar beschikbare herstelcodes apart van je telefoon.

Kunnen meerdere medewerkers hun eigen code gebruiken?

Bij persoonlijke accounts koppelen we de verificatie per gebruiker. Zo hoeft een team geen wachtwoord of telefoon te delen en kunnen rechten en toegang per persoon worden gewijzigd.

Is een code op je telefoon voldoende bescherming?

Tweestapsverificatie voegt een controle toe. Een betrouwbare inrichting vraagt ook om goede wachtwoorden, passende rechten, onderhoud en oplettend gebruik. Een code kan nog steeds worden buitgemaakt via een misleidende inlogpagina. Deel codes niet en controleer waar je inlogt. Voor extra bescherming kunnen we de mogelijkheden van passkeys of beveiligingssleutels bespreken.

Kunnen we met ons bestaande bedrijfsaccount inloggen?

We kunnen onderzoeken of aanmelden via jullie identiteitsprovider aansluit op de applicatie en het abonnement dat je gebruikt. De mogelijkheden voor centraal inloggen, extra verificatie en accountbeheer nemen we mee in het voorstel.

Bronnen en beeldmateriaal

De inlogvoorbeelden zijn opgebouwd in een neutrale huisstijl, zonder klantgegevens, wachtwoorden of echte verificatiecodes. De Google-afbeeldingen zijn ongewijzigde openbare screenshots uit de officiële Google Play-vermelding. Productnamen en beeldmerken blijven van hun rechthebbenden.

Meer uitleg: Google Authenticator en OWASP over wachtwoordopslag.

Een werkplek die past bij je bedrijf én je gegevens.

We denken mee over toegang, rollen, koppelingen en beheer voor jouw dashboard of webapp.

Bespreek jouw webapp

Meer over modulaire webapps →Het projectverhaal van Olympus Bouw →

Onze werkwijze

Wat je van OptiCore kunt verwachten.