10. Bedenk eens wat er mis kan gaan…
• Fraude met cijferadministratie
• Lekken van patenten/
onderzoeksdata
• Persoonlijke gegevens van
gebruikers op straat
• Etc., etc.
11. Ook/ juist in onderwijs behoefte aan veiligere
toegang
12. Hoe organiseer je dat als instelling?
• Veel integratie-effort bij instelling (n=160)
• Per clouddienst een nieuw token?
• Zoveel leveranciers, zoveel tokens. Vendor lock-in
dreigt
• €€€ Duur, vooral bij kleine user base
• Uitgifteprocessen belangrijk voor betrouwbaarheid
14. Wat willen we bieden:
• Betere toegangsbeveiliging tot clouddiensten
• Beperken van risico’s op beveiligingsincidenten
• Eenvoudige uitrol (techniek + proces)
• Concurrerend tariefmodel
• Gemak voor de eindgebruiker:
uniforme toegang met één tweede factor voor meerdere
diensten
19. Huidige status dienstontwikkeling
Prototype self-service portal voor registratie token
Prototype appplicatie voor ID-check user + activeren token
Beschikbare tokens in prototype: SMS en Yubikey
Op basis van prototype uitvoeren pilots met instellingen
Business model + business case uitwerken ism instellingen
Pilots succesvol? Dan: dienstontwikkeling, toevoegen aan
SURFconext
20. Doelen pilots
• Wat is nodig om een clouddienst geschikt te maken voor
sterke authentciatie? (time, effort, technical, knowledge)
• Hoe kan een clouddienst differentiëren tussen verschillende
betrouwbaarheidsniveaus gebruiker?
(= alleen op relevante plekken in applicatie afdwingen)
• Hoe organiseren we uitgifteproces tokens?
• Hoe is user experience voor eindgebruiker & Service Desk?
22. Ervaringen Service Desk mbt
registratieproces
Werkt prima, proces reeds bekend van uitgifte andere
middelen
Check legitimatie wordt over algemeen serieus genomen
Registratieproces eenvoudig op te schalen naar grotere
groepen gebruikers
23. Ervaringen eindgebruikers
Registratieproces werkt prima
Gebruikers waarderen keuzevrijheid in token (SMS/ Yubikey)
User experience bij switch tussen applicaties met hoger/
lager LoA in orde
Telefoon laat een gebruiker niet gauw slingeren
! Yubikey in gedrag nu soms nog onveilig; laat je gemakkelijk
in USB-poort zitten instructies verbeteren!
24. Overige leerpunten 1e pilot
Sterke authenticatie via SURFconext werkt
Applicatie kan goed omgaan met verschillende betrouwbaarheidsniveaus
± ‘Evt. opstartproblemen’ zouden ook bestaan als instelling zelf sterke
authenticatie zou implementeren
! Differentiëren in betrouwbaarheidsniveau nog lastig voor SP (alles of
niets)
! Duidelijkere instructies nodig over veilig gebruik van tokens
! Afhankelijkheid van SURFconext kan extra risico betekenen
! Tariefmodel nog onduidelijk (work in progress)
27. Overige observaties nav gesprekken
instellingen
• Veel interesse bij instellingen in sterke authenticatie
• Scope wisselt: zowel online als lokale systemen
• Niet elke use-case geschikt (looptijd/ techniek/ etc)
Disclaimer:
Dit wordt NIET de holy grail voor alle authenticatie-issues naar lokale (beheer)systemen!
Want: Step-up-authentication-as-a-service alleen voor webbased SPs
31. Veilige toegang: risico-afweging nodig
• Hoe bepaal je vereiste
betrouwbaarheidsniveau?
• Wat is juiste risico-
inschatting?
• Wat is gewenste
beschermingsniveau?
Volg internationale
standaarden:
• ISO 29115
• NIST 800-63
• STORK
http://www.surf.nl/kennis-en-innovatie/kennisbank/2014/rapport-handreiking-betrouwbaarheidsniveaus.html
32. Bron: ISO 29115
Betrouwbaarheidsniveaus - Levels of
Assurance
LoA Beschrijving
1 - Laag Weinig of geen vertrouwen in geclaimde over verzekerd (“asserted”)
identiteit
2 - Medium Enig vertrouwen in de geclaimde of verzekerde identiteit
3 - Hoog Veel vertrouwen in de geclaimde of verzekerde identiteit
4 - Zeer hoog Zeer veel vertrouwen in de geclaimde of verzekerde identiteit
1 wachtwoord is genoeg. Met je instellingsaccount krijg je toegang tot veelheid (400+) cloudapplicaties
SURFconext is stopcontact, instellingen & leveranciers pluggen daar in met hun stekker
Partijen maken vooraf afspraken over technologische standaarden, trust en voorwaarden voor gebruik. Een manier om gebruikers van verschillende achtergrond (bank, onderwijsinstelling) toegang te geven tot diensten van derden (webwinkels, pinautomaat, overheidsdiensten, wifi)
Via SURFconext toegang tot veelheid aan externe diensten, lokaal inloggen bij IdP, wachtwoord verlaat instelling niet. SP vertrouwt op authenticatie bij de IdP
Authenticatie dmv username/ password voldoet in gros van de gevallen bijv voor toegang tot wetenschappelijke content (vergelijk: vroeger gebeurde dit op basis van IP)
Maar ook bij webwinkels en andere collaboration tools is username/ pw vaak voldoende
Maar is username/ password nog wel voldoende?
Sommige applicatie bevatten echter wat meer gevoelige data, denk aan: SIS, loonadministratie, DNS-beheer. Je wilt dan meer zekerheid over wie er ‘in’ zo’n applicatie kan => dat stelt ook strengere eisen aan de manier van authenticeren + het daar aan voorafgaande registratieproces
De vraag stellen, is hem beantwoorden. Beveiliging van applicaties met username/ passwords is vaak onvoldoende. Met name wanneer een applicatie gevoelige data bevat. Instelling verantwoordelijk
Probleem is niet nieuw. Instellling implementeren (op kleine schaal) al sterke authenticatie oplossingen. Maar lopen daar tegen drempels aan.
Waarom moeilijk doen als het ook makkelijk kan. Waarom 160x het wiel uitvinden, als je ook een gezamenlijke, gestandaadiseerde oplossing kunt bieden voor hele sector?
Uitgifteproces lokaal op instelling, maar centrala infrastructuur
Deze stap is belangrijk omdat je zo vastlegt dat het gekozen token is gekoppeld aan een specifieke gebruiker
Roosterinformatiesysteem
LoA 0 = niet inloggenLoA 2 = Sterk authenticatie
Verregaande aanpassingen aan applicatie nodig als je wilt differentiëren in betrouwbaarheidsniveau
Moeilijk als je afhankelijk bent van leverancier*
*) 80% van het werk is standaard SAML-koppeling SURFconext
Roosterinformatiesysteem
Studentinformatiesysteem o.a. cijferadministratie
1e gesprek met CACI/Osiris was erg positief, ism Hanzehogeschool gaan we verkennen of we hier een pilot voor kunnen starten
Ism SURFmarket lopen er verkennende gesprekken met leveranciers, concept moet ‘landen’ er moet bereidheid komen bij leveranciers om step-up authenticatie te implementeren in applicaties
Hoe gaan we diensten bewegen tot het afdwingen van sterke authenticatie?
Hoe kun je het voor een dienst zo makkelijk mogelijk maken om sterke authenticatie te consumeren in zijn applicatie?
Hoe zorgen we voor gebruiksgemak?
Kennis, ervaring, samen!
Handreiking beschikbaar waarmee instelling kan inschatten wanneer sterke authenticatie wel/ niet vereist is
Goed om te realiseren dat het Level of Assurance van de gebruiker gebaseerd is op de combinatie van het token & de identiteit !!!
Als een willekeurige persoon een Yubikey als 2e factor gebruikt, dan weet ik alleen dat een gebruiker een sterk middel heeft, maar als ik in mijn proces de koppeling maak tussen Jan Jansen van Hogeschool Windesheim en een token met serienummer xx112233 ahv paspoortcontrole, dan weet ik met iets meer zekerheid dat de gebruiker die met zijn federatieve identieit EN het token xx112233 inlogt, Jan Jansen van Hogeschool Windesheim is