ISD Productcodes iWmo en iJw
-
Nu een standaardproductcodetabel beschikbaar is gekomen, wordt de ondersteuning voor gemeentespecifieke lijsten in 2016 teruggebracht. Het is nog steeds mogelijk om met afwijkende codes te werken, maar gemeenten zijn zelf verantwoordelijk om daarover afspraken te maken met zorgaanbieders en de codetabellen beschikbaar te stellen.
De Verwijsindex productcodes Wmo en Jeugd, een centrale voorziening voor gemeente-specifieke lijsten, zal in 2016 nog wel raadpleegbaar blijven, maar mutaties zijn niet meer mogelijk.
-
In het iWmo- en iJw-berichtenverkeer worden vanaf versie 2.0 drie uitvoeringsvarianten onderscheiden: inspannings-, output- en taakgericht.
De standaardproductcodetabel is bruikbaar in de inspannings- en outputgerichte uitvoeringsvariant, waar de gemeente op cliëntniveau gegevens uitwisselt met de aanbieder van zorg of ondersteuning.
- Handreiking Uitvoeringsvarianten iWmo en iJw (VNG, augustus 2015, pdf)
ISD SaaS informatiebeveiliging en privacy
-
Jaarlijks is een TPM of eigen audit nodig. Maak vooraf afspraken met betrekking tot het zogenoemde ‘right to audit’, zodat de gemeente of een auditor in opdracht van de gemeente in staat gesteld wordt om bepaalde processen en de gegevensverwerking te kunnen controleren en beoordelen.
-
De beveiligingseisen zijn afhankelijk van de soort gegevens, applicatie en dienst die u als gemeente in de SaaS-oplossing (Software as a Service) wilt gaan gebruiken. Een voorbeeld is te vinden in het operationele Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)-product Bewerkersovereenkomst van de Informatie Beveiligingsdienst (IBD). Hierin zijn ook de moogelijke maatregelen opgenomen.
Als gemeente bent u zelf verantwoordelijk voor het maken van een inschatting of de genomen maatregelen afdoende dekkend zijn voor de risico's die gelopen worden.
-
Toegang voor burgers kan op dezelfde manier geregeld worden als bij een eigen oplossing vanuit de gemeente. Er moet een portaal komen waar de burger met DigiD kan inloggen, waar de informatie dan getoond wordt als er een klantcase is. Bij SaaS moet er dus een portaal zijn die aparte informatie ontsluit. Een mogelijke oplossing is de digitale berichtenbox van mijnoverheid.nl.
-
Bij een SaaS-oplossing gaat de gemeente niet meer over functioneel en technisch beheer. Functioneel beheer zoals het (functioneel) parametriseren van de applicatie en gebruikersbeheer kan nog wel door de gemeente worden uitgevoerd.
- BIG - Cloud computing (IBD, november 2013, pdf)
-
Het identificatie- en authenticatieproces is het vaststellen wie iemand is. Het autorisatieproces is het bepalen en vastleggen welke toegang deze persoon heeft binnen een bepaald informatiesysteem. De autorisatie kan met speciale tooling worden beheerd (IAM-tools) en indien een koppeling bestaat met een applicatie kunnen de gegevens worden uitgewisseld.
Er zijn niet veel gemeenten die dit op deze manier doen. In de praktijk staan eindgebruikers in een adresgids (LDAP of active directory). Los daarvan wordt vaak per applicatie bijgehouden welke eindgebruikers waar toegang hebben in de applicatie zelf. Dit is vaak een handmatig proces op basis van bijvoorbeeld een getekend autorisatieformulier van een manager. Deze autorisaties worden dan door een functioneel beheerder middels een aparte beheerpagina in een webapplicatie verwerkt.
- BIG - Beleid logische toegangsbeveiliging (IBD, juli 2014, pdf)
-
Vanaf welke locaties toegang tot de SaaS-oplossing moet worden toegestaan is van een aantal zaken afhankelijk, zoals:
- de gegevens (inhoud)
- de plaats (geografisch)
- wetgeving (soms is het niet toegestaan met bepaalde gegevens te werken buiten de gemeentelocatie)
Meer informatie
- BIG - Handreiking Dataclassificatie (IBD, april 2018, pdf)
- BIG - Cloud computing (IBD, november 2013, pdf)
- BIG - Mobile Device Management (IBD, oktober 2013, pdf)
- BIG - Telewerkbeleid (IBD, april 2014, pdf)
-
Volledige vraag
Hoe garandeer ik de continuïteit van de SaaS-applicatie en de beschikbaarheid van de data in geval van een faillissement van de SaaS-leverancier, of wanneer de leverancier anderszins in gebreke blijft?Antwoord
Zowel de gemeente (cloudafnemer) als hun leveranciers dienen hun verantwoordelijkheid te nemen, door bijvoorbeeld een continuïteitsplan op te stellen. Het doel van dit continuïteitsplan is het onafgebroken gebruik veilig stellen. De calamiteit bij de cloud- of SaaS-leverancier moet zo min mogelijk gevolgen hebben voor de bedrijfsprocessen van de afnemer.Neem minimaal de volgende onderwerpen in een contract op:
- dat de data altijd eigendom blijft van de gemeente en in een vastgesteld formaat verstrekt wordt in bepaalde omschreven situaties;
- broncode-escrowregeling zodat het gebruik, toegang, onderhoud en doorontwikkeling van de software wordt gewaarborgd;
- exitstrategie (exitplan), voor het geval dat de leverancier niet bevalt of niet meer kan leveren.
Meer informatie
- BIG - Cloud computing (IBD, november 2013, pdf)
-
Koppelingen tussen vertrouwde netwerken en niet-vertrouwde netwerken moeten bij voorkeur op de volgende manier worden beveiligd:
- Kanaalencryptie door middel van een PKIoverheid-SSL certificaat
- Apparaat authenticatie door middel van een PKIoverheid certificaat
- Filtering op basis van IP-nummers
- Scheiding van netwerken met verschillende beveiligingsniveaus
- Indringerdetectie
- (Technische) logging
Meer informatie
- BIG - Encryptiebeleid (PKI) (IBD, juni 2014, pdf)
- BIG - Aanwijzing logging (IBD, januari 2014, pdf)
- ICT-Beveiligingsrichtlijnen voor Webapplicaties (Nationaal Cyber Security Centrum | NCSC)
- NORA online (Nederlandse Overheid Referentie Architectuur | NORA)
-
Lees de volgende operationele BIG-producten:
- Inkoopvoorwaarden en informatiebeveiligingseisen (IBD, januari 2014, pdf)
Aanscherpen van de gemeentelijke inkoop voorwaarden. - Contractmanagement (IBD, april 2014, pdf)
Aandachtspunten voor contractmanagement, inkoop en beveiligingseisen.
- Inkoopvoorwaarden en informatiebeveiligingseisen (IBD, januari 2014, pdf)
Islamitisch begraven en eeuwigdurende grafrust
-
Voor de beantwoording is artikel 23 Wlb tweede lid relevant. Dit artikel luidt: "Begraving geschiedt in een algemeen graf, waarbij de houder van de begraafplaats bepaalt wie daarin wordt begraven, dan wel in een particulier graf, zijnde een graf waarop een uitsluitend recht is gevestigd, waarbij de rechthebbende bepaalt wie daarin wordt begraven."
Gemeenten mogen in hun beheer verordening bepalen dat alleen graven worden uitgegeven aan inwoners van de gemeente, of gemeenten als sprake is van een gezamenlijke begraafplaats. Overigens is dit niet altijd houdbaar. Geadviseerd wordt om in de regeling een hardheidsclausule op te nemen, zodat in situaties waarin de regeling tot een onvoorzien en onredelijk benadelend gevolg voor de betreffende burger zou leiden een uitzondering kan worden gemaakt (bijvoorbeeld wanneer niet in de gemeente wonende echtgenoten of voormalige inwoners in de gemeente begraven willen worden.) Als er in het verleden op de gemeentelijke begraafplaats particuliere graven zijn uitgegeven onder een model beheerverordening begraafplaatsen waarin niet is opgenomen dat alleen inwoners in het graf begraven mogen worden, dan zal voor een wijziging van die beheer verordening passend overgangsrecht getroffen moeten worden.
Kerkgenootschappen mogen in hun reglement voor hun bijzondere begraafplaats bepalen dat alleen graven worden uitgegeven aan leden van dat kerkgenootschap en ook andere beheerders van bijzondere begraafplaatsen zijn vrij te bepalen aan wie grafrechten worden uitgegeven. Voor bijzondere begraafplaatsen kan de gemeente niet als voorwaarde stellen dat alleen inwoners van de eigen gemeente op de begraafplaats begraven mogen worden. Inherent aan bijzondere begraafplaatsen is dat zij zelf mogen bepalen wie er begraven wordt en zelf mogen bepalen hoe zij invulling geven aan het begraven, in overeenstemming met hun eigen tradities en rituelen.