Standaarden:Beveiligd Gegevenstransport/controle procedure: verschil tussen versies

Uit Kennisnet Developers Documentatie
Naar navigatie springen Naar zoeken springen
(Nieuwe pagina aangemaakt met '== Controle procedure naleving beveiligingseisen == De implementatie engineer bij Kennisnet zal naleving van de in het PvE genoemde eisen controleren. Deze controle...')
 
 
Regel 1: Regel 1:
  +
'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''
  +
 
== Controle procedure naleving beveiligingseisen ==
 
== Controle procedure naleving beveiligingseisen ==
 
De implementatie engineer bij Kennisnet zal naleving van de in het PvE genoemde eisen controleren. Deze controle bestaat uit de jaarlijkse kwalificatie na oplevering van de nieuwe functionaliteiten en eisen, ontwikkeld voor een specifieke keten. Daarnaast zal de implementatie engineer periodiek steekproeven houden om de kwaliteit van de keten te waarborgen.<br/>
 
De implementatie engineer bij Kennisnet zal naleving van de in het PvE genoemde eisen controleren. Deze controle bestaat uit de jaarlijkse kwalificatie na oplevering van de nieuwe functionaliteiten en eisen, ontwikkeld voor een specifieke keten. Daarnaast zal de implementatie engineer periodiek steekproeven houden om de kwaliteit van de keten te waarborgen.<br/>

Huidige versie van 21 jun 2021 om 11:46

Let op, deze voorschriften worden vervangen door de Uniforme Beveiligingsvoorschriften

Controle procedure naleving beveiligingseisen

De implementatie engineer bij Kennisnet zal naleving van de in het PvE genoemde eisen controleren. Deze controle bestaat uit de jaarlijkse kwalificatie na oplevering van de nieuwe functionaliteiten en eisen, ontwikkeld voor een specifieke keten. Daarnaast zal de implementatie engineer periodiek steekproeven houden om de kwaliteit van de keten te waarborgen.
Deze tests verlopen middels voorgeschreven scripts, waardoor er een uniforme controle uitgevoerd kan worden.

De testprocedure bestaat uit minimaal een:

  • Functionele test: werkt de koppeling tussen LAS en TC en tussen LAS en LAS zoals voorgeschreven
  • Technische test: worden alle beveiligingseisen zoals opgenomen op deze wiki daadwerkelijk correct uitgevoerd

Technische test

In hoofdlijnen opgesomd wat er binnen de technische test gecheckt wordt:

  • Klopt het server certificaat van het systeem waarop het aanleverpunt wordt aangeboden?
    • Is het certificaat nog geldig?
    • Komt servername in het certificaat overeen met de domeinnaam in de url?
    • Is het certificaat en de certificaatketen te valideren tegen het root CA certificaat?
    • Is het certificaat niet ingetrokken (revoked) door de CA?
    • Welke hash signatuur wordt er gebruikt?
  • Wordt SNI gesupport?
  • Wat voor private key wordt er gebruikt en met welke sleutellengte?
  • Geeft de server aan in de TLS handshake of deze bepaalde client certificaten verwacht?
  • Ondersteunt de server 'secure renegotiation'?
  • Ondersteunt de server 'secure client-initiated renegotiation'?
  • Ondersteunt de server 'insecure client-initiated renegotiation'?
  • Ondersteunt de server OCSP stapling?
  • Ondersteunt de server serverside cipher ordering?
  • Ondersteunt de server TLS compression?
  • Ondersteunt de server session resumption caching?
  • Ondersteunt de server session resumption tickets?
  • Ondersteunt de server SCSV fallback?
  • Ondersteunt de server HSTS?
  • Is de server vatbaar voor de CCS vulnerability?
  • Is de server vatbaar voor TLS poodle?
  • Is de server vatbaar voor Heartbleed?
  • Accepteert de server alleen de voor de keten geaccepteerde client certificaten?
    • Test met een PKIoverheid certificaat
    • Test met een random ander client certificaat verkregen uit een legitieme CA in de markt
    • Test met een self-signed certificaat
  • Welke TLS/SSL protocollen ondersteunt de server?
  • Welke ciphersuites ondersteunt de server?