| Principe 1: Bescherming van gegevens in-transit |
| 1.1 Versleuteling | Atlassian behoudt versleuteling op het interne draadloze netwerk, waaronder het wijzigen van de standaardinstellingen van de leverancier. Het Workplace Technology-team van Atlassian beschermt onze draadloze netwerken door gebruik te maken van WPA2-AES-authenticatie en PEAP-EAP-MSCHAPv2-versleuteling. We authenticeren op ons draadloze netwerk via 802.1x met behulp van ons interne identiteitsarchief. We scannen regelmatig naar frauduleuze draadloze toegangspunten en houden een lijst bij van gevonden frauduleuze toegangspunten.
Atlassian gebruikt de industriestandaard Transport Layer Security ('TLS') versie 1.2 om een veilige verbinding tot stand te brengen met behulp van 256-bits Advanced Encryption Standard ('AES')-versleuteling. Servers die gebruikersgegevens bevatten, gebruiken de toonaangevende AES-versleuteling voor volledige schijf. Tenantgegevens worden versleuteld in de AWS RDS- of RDS-back-ups en worden ook versleuteld in langdurige opslag (S3) en in alle bijlagen.
Ga voor meer informatie naar https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management | Ons beveiligings- en gegevensprivacybeleid
Gegevensversleuteling | Gegevens van het Atlassian Trust Center
Versleuteling | Atlassian Cloud-architectuur en operationele praktijken |
| 1.2 Netwerkbescherming | Het Policy Management Program (PMP) van Atlassian omvat een communicatiebeveiligingsbeleid waarin de verantwoordelijkheid voor het beheer van het netwerk is vastgelegd.
Voor toegang tot het netwerk gebruikt Atlassian een gecentraliseerde map met LDAP dat toegangscontrole op basis van rollen implementeert op basis van gedefinieerde profielen. Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. De regels voor toegang tot interne productienetwerken worden gehandhaafd door gebruik te maken van expliciet aangewezen beveiligingsgroepen binnen AWS VPC-omgevingen.
Het Workplace Technology-team van Atlassian beschermt draadloze netwerken door gebruik te maken van WPA2-AES-authenticatie en PEAP-EAP-MSCHAPv2-versleuteling. We authenticeren op ons draadloze netwerk via 802.1x met behulp van ons interne identiteitsarchief.
Atlassian Network Engineering maakt gebruik van IPS-technologieën die zijn ingebouwd in onze firewalls in de cloud en op kantoor. Ook hebben we IDS-technologieën geïmplementeerd in onze kantooromgevingen. De bescherming tegen netwerkbedreigingen wordt uitgevoerd door AWS, waaronder DDoS-bescherming en enkele firewallfuncties voor webtoepassingen.
Alle gegevens voor onze diensten worden tijdens het transport versleuteld met behulp van TLS om ze te beschermen tegen ongeoorloofde openbaarmaking of wijziging, of dat nu via HTTPS of SMTPS gebeurt. Atlassian-implementaties van TLS dwingen het gebruik van sterk vercijferde tekst af. | Ons beveiligings- en gegevensprivacybeleid
Beveiliging inbouwen in onze netwerkinfrastructuur | Atlassian Trust Center |
| 1.3 Verificatie | Atlassian handhaaft beperkingen voor het personeel dat deze toegang nodig heeft voor hun functie en verantwoordelijkheden. Alle niveau 1-systemen worden beheerd via de centrale enkelvoudige aanmelding (SSO) en mapoplossing van Atlassian. Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. Atlassian maakt gebruik van MFA voor toegang tot alle niveau 1-systemen. We hebben tweefactorauthenticatie mogelijk gemaakt voor de hypervisorbeheerconsole en de AWS-API, en we geven een dagelijks auditrapport uit over alle toegang tot de hypervisorbeheerfuncties. De toegangslijsten voor de hypervisorbeheerconsole en de AWS-API worden elk kwartaal herzien. We zorgen ook voor een synchronisatie van elke 8 uur tussen ons HR-systeem en ons identiteitsarchief.
Atlassian ondersteunt het gebruik van Google-, Microsoft- en Apple-ID's voor authenticatie van de meeste producten. Ook ondersteunen we SAML voor onze Atlassian-cloudservices via Atlassian Access; bekijk hiervoor https://www.atlassian.com/enterprise/cloud/access | Ons beveiligings- en gegevensprivacybeleid
Toegang tot onze netwerken beveiligen via ZeroTrust | Atlassian Trust Center Service
Authenticatie en authorisatie | Atlassian Cloud-architectuur en operationele praktijken |
| Principe 2: Bescherming van assets en veerkracht |
| 2.1 Fysieke locatie en rechtsbevoegdheid | Fysieke locatie
Op dit moment heeft Atlassian datacenters en host data in de VS, Duitsland, Ierland, Singapore en Australië. We leveren alle klanten veilige, snelle en betrouwbare diensten door hun content te hosten in meerdere regio's over de hele wereld.
Alle Atlassian Cloud-productiesystemen bevinden zich in de regio's VS-Oost en VS-West van Amazon AWS, de regio AWS Ireland, de regio AWS Frankfurt, de regio AWS Sydney en de regio AWS Singapore.
Het platform van Atlassian optimaliseert bij aanmelding waar klantgegevens opgeslagen worden op basis van waar de toegang vandaan komt, voor betrouwbaardere prestaties en minder latentie.
Gegevenslocatie is nu beschikbaar als onderdeel van onze Cloud Standard-, Premium- en Enterprise-abonnementen voor Jira Software, Confluence en Jira Service Management. Je kunt er ook voor kiezen om bepaalde productgegevens op te slaan in Australië, Europa of de Verenigde Staten. Meer informatie over regelingen voor gegevenslocatie.
Houd onze cloud-roadmap in de gaten voor de nieuwste updates, waaronder gegevenslocatie voor aanvullende locaties, gegevenslocatie voor apps en meer. | Fysieke locatie
Gegevens beveiligen | Atlassian Trust Center
Atlassian Cloud-hostinginfrastructuur | Atlassian Cloud-architectuur en operationele werkwijzen |
| Gebruik van je gegevens
Raadpleeg de Klantovereenkomst, het Privacybeleid en het Addendum voor gegevensverwerking van Atlassian. | Gebruik van je gegevens
Klantovereenkomst van Atlassian | Atlassian
Privacybeleid | Atlassian
Addendum voor gegevensverwerking | Atlassian |
| Aanvullende overwegingen
Raadpleeg Atlassian's AVG-naleving en andere wetgeving inzake gegevensbescherming. | Aanvullende overwegingen
AVG-naleving | Atlassian | Atlassian |
| 2.2 Beveiliging van Data Center | Dit wordt behandeld in het Addendum voor gegevensverwerking van Atlassian, waarin Atlassian toezeggingen doet om je gegevens te beschermen, onder meer met betrekking tot beveiliging van datacenter, netwerk en gegevens.
Atlassian anticipeert op fysieke bedreigingen voor zijn datacenters en heeft tegenmaatregelen genomen om de impact van deze bedreigingen te voorkomen of te beperken.
Onze Atlassian-vestigingen laten zich leiden door ons interne beleid inzake fysieke beveiliging en omgevingsbeveiliging, waaronder het monitoren van fysieke in- en uitgangen.
De Data Centers van onze partners beschikken over meerdere nalevingscertificeringen. Deze certificeringen hebben betrekking op fysieke beveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantprovisioning en probleembeheer. Toegang tot de Data Centers wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: bewakers op locatie, videobewaking, toegangssluizen en aanvullende maatregelen voor inbraakbeveiliging.
AWS onderhoudt meerdere certificeringen voor de bescherming van hun datacenters. Informatie over de fysieke bescherming van AWS is te vinden op: http://aws.amazon.com/compliance/ | Ga naar
https://www.atlassian.com/trust/security/securitypractices#physical-security |
| 2.3 Gegevenscodering | Atlassian behoudt versleuteling op het interne draadloze netwerk, waaronder het wijzigen van de standaardinstellingen van de leverancier. Het Workplace Technology-team van Atlassian beschermt onze draadloze netwerken door gebruik te maken van WPA2-AES-authenticatie en PEAP-EAP-MSCHAPv2-versleuteling. We authenticeren op ons draadloze netwerk via 802.1x met behulp van ons interne identiteitsarchief. We scannen regelmatig naar frauduleuze draadloze toegangspunten en houden een lijst bij van gevonden frauduleuze toegangspunten.
Atlassian gebruikt de industriestandaard Transport Layer Security ('TLS') versie 1.2 om een veilige verbinding tot stand te brengen met behulp van 256-bits Advanced Encryption Standard ('AES')-versleuteling. Servers die gebruikersgegevens bevatten, gebruiken de toonaangevende AES-versleuteling voor volledige schijf. Tenant-gegevens worden versleuteld in de AWS RDS- of RDS-back-ups en worden ook versleuteld in langdurige opslag (S3) en in alle bijlagen. Ga voor meer informatie naar https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management | Ons beveiligings- en gegevensprivacybeleid
Gegevensversleuteling | Gegevens van het Atlassian Trust Center
Versleuteling | Atlassian Cloud-architectuur en operationele praktijken |
| 2.4 Opschonen van gegevens en verwijdering van apparatuur | Atlassian hanteert een standaard voor gegevensbehoud en -vernietiging, die aangeeft hoelang we verschillende soorten gegevens moeten bewaren. Gegevens worden geclassificeerd in overeenstemming met ons Atlassian-beleid inzake gegevensbeveiliging en levenscyclus van informatie, en op basis daarvan worden controles geïmplementeerd.
Voor klantgegevens: na beëindiging van een Atlassian-contract worden de gegevens van een klantenteam verwijderd uit de live productiedatabase en worden alle bestandsbijlagen die rechtstreeks naar Atlassian zijn geüpload binnen 14 dagen verwijderd. De gegevens van het team blijven in versleutelde back-ups staan totdat de bewaartermijn van 90 dagen voor back-ups vervalt. Daarna worden de gegevens vernietigd in overeenstemming met ons Atlassian-beleid voor gegevensbehoud. In het geval dat een databaseherstel nodig is binnen 90 dagen na het verwijderen van de gevraagde gegevens, verwijdert het operationele team de gegevens opnieuw zo snel als redelijkerwijs mogelijk nadat het live productiesysteem volledig is hersteld. Ga voor meer informatie naar https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ | Behoud en verwijdering van gegevens | Atlassian Trust Center
Houd de opslag bij en verplaats gegevens tussen producten | Atlassian-support |
| 2.5 Fysieke veerkracht en beschikbaarheid | Fysieke beveiligingscontroles in onze kantoren worden geleid door ons beleid voor fysieke beveiliging en omgevingsbeveiliging, dat ervoor zorgt dat overal op locatie in onze omgevingen en in de cloud betrouwbare fysieke beveiliging geïmplementeerd is. Dit beleid heeft betrekking op gebieden als veilige werkruimten, om onze IT-apparatuur op iedere locatie te beveiligen, toegang tot onze kantoren en gebouwen te beperken tot alleen het juiste personeel en fysieke in- en uitgangen te bewaken. Onze fysieke beveiligingsmaatregelen omvatten een bemande receptie tijdens kantooruren, verplichte registratie voor bezoekers, badges voor toegang tot niet-publieke ruimtes, samenwerking met het management van onze kantoorgebouwen voor toegang buiten kantooruren en videoregistratie bij in- en uitgangen, zowel voor hoofdingangen als laadgebieden.
De datacenters waar wij mee werken voldoen minimaal aan SOC-2. Deze certificeringen hebben betrekking op verscheidene beveiligingsmaatregelen, waaronder fysieke beveiliging en bescherming en omgevingsbeveiliging en -bescherming. Toegang tot de datacenters wordt beperkt tot geautoriseerd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten bewakers op locatie, videobewaking, sluizen en aanvullende maatregelen voor inbraakbeveiliging.
Naast bovenstaande maatregelen publiceren we ook de beschikbaarheidsstatus van onze services in realtime voor klanten die ons eigen Statuspage-product gebruiken. Als er problemen zijn met een van onze producten weten onze klanten dat zodra wij het weten. | Fysieke beveiliging | Atlassian Trust Center |
| Principe 3: Scheiding tussen klanten |
| | Hoewel onze klanten een algemene cloudgebaseerde IT-infrastructuur delen wanneer ze de producten van Atlassian gebruiken, hebben we maatregelen getroffen om er zeker van te zijn dat ze logisch gescheiden zijn, zodat de acties van één klant de gegevens of service van andere klanten niet in gevaar kunnen brengen.
De aanpak van Atlassian om dit te bereiken verschilt in onze applicaties. We gebruiken voor Jira en Confluence Cloud een concept dat we 'tenantcontext' noemen om de logische scheiding van onze klanten te bereiken. Dit wordt zowel geïmplementeerd in de applicatiecode als beheerd door de Tenant Context Service (TCS) die we gebouwd hebben. Dit concept zorgt ervoor dat:
- De gegevens at-rest van iedere klant logisch gescheiden gehouden zijn van andere klanten
- Alle aanvragen die verwerkt worden door Jira en Confluence hebben een 'tenant-specifieke' weergave zodat ze geen invloed hebben op andere tenants
In brede zin werkt het TCS door een 'context' op te slaan voor individuele klanttenants. De context voor iedere tenant wordt gekoppeld aan een uniek ID dat centraal is opgeslagen door het TCS en dat een reeks metagegevens bevat die bij die tenant hoort (zoals in welke databases de tenant zit, welke licenties de tenant heeft, welke functies de tenant toegang toe heeft en andere configuratie-informatie). Als een klant Jira of Confluence Cloud gebruikt, gebruikt de TCS de tenant-ID om die metadata te ordenen en deze te koppelen aan alle activiteiten die de tenant in de applicatie uitvoert gedurende de sessie.
De context die de TCS levert, fungeert effectief als 'lens' waardoor alle interacties met klantgegevens plaatsvinden. Die lens is altijd beperkt tot één specifieke tenant. Op deze manier garanderen we dat één klanttenant geen toegang heeft tot de gegevens van een andere tenant, en dat één tenant geen invloed kan hebben op de service van een andere tenant.
Meer informatie over onze cloudarchitectuur is beschikbaar als onderdeel van onze cloudsupportresources. | Atlassian Cloud-architectuur en operationele praktijken | Atlassian Trust Center |
| Principe 4: Toezichtskader |
| | Atlassian erkent dat gereguleerde entiteiten in het kader van hun risicobeoordelingen onze interne controles, systemen en gegevensbeveiliging en privacybescherming voor de services moeten herzien. Atlassian ondergaat jaarlijks verschillende audits door onafhankelijke derden om onze activiteiten en interne controles te verifiëren.
Ga voor ons huidige nalevingsprogramma naar ons Compliance Resource Center voor toegang tot alle downloadbare verificatie en certificeringen van onze producten.
Atlassian heeft een Enterprise Risk Management (ERM)-programma dat is afgestemd op het COSO-risicomodel en ISO 31000. Het ERM-programma implementeert een kader en methodologie voor risicobeheer in Atlassian en voert jaarlijkse risicobeoordelingen, periodieke specifieke risicobeoordelingen van een productomgeving en functionele risicobeoordelingen uit, indien nodig, op basis van het risicoprofiel.
Het risicobeheerkader van Atlassian biedt met name normen, processen, rollen en verantwoordelijkheden, aanvaardbare risicotoleranties en richtlijnen voor de voltooiing van risicobeoordelingsactiviteiten. Onze risicobeheerprocessen en -praktijken zijn bepalend voor de voltooiing van onze risicobeoordelingen, die herhaalbaar zijn en resultaten opleveren die geldig, consistent en vergelijkbaar zijn. De risicobeoordelingen die Atlassian uitvoert, omvatten waarschijnlijkheid en impact van alle risicocategorieën, en de behandeling van alle risico's in vergelijking met onze intern ingestelde risicobereidheid. In alle fasen van het ERM-programma communiceert het Risk & Compliance-team met de relevante belanghebbenden en raadpleegt het relevante kleine en middelgrote ondernemingen. | Ons beveiligings- en gegevensprivacybeleid
Compliance en risicobeheer | Atlassian Trust Center
Ons Atlassian Trust Management System (ATMS) | Atlassian Trust Center
Addendum voor gegevensverwerking | Atlassian Trust Center |
| Principe 6: Operationele beveiliging |
| 5.1 Kwetsbaarheidsbeheer | Atlassian werkt er voortdurend aan om de ernst en frequentie van kwetsbaarheden in onze producten, diensten en infrastructuur te verminderen en om geconstateerde kwetsbaarheden zo snel mogelijk op te lossen. Om dit mogelijk te maken, hebben we een veelzijdige en voortdurend ontwikkelende aanpak geïmplementeerd die gebruik maakt van zowel geautomatiseerde als handmatige processen om kwetsbaarheden binnen onze applicaties en infrastructuur op te sporen, te volgen en op te lossen.
Voor al onze producten en services hebben we een uitgebreid proces voor probleemoplossing (waarbij gebruik wordt gemaakt van ons eigen product Jira, dat problemen vastlegt en ons helpt om aanvragen op te lossen). Hieraan ten grondslag liggen talloze beleidsregels voor het oplossen van beveiligingsbugs, adviesservices en SLO's waaraan we ons houden. We behandelen bugrapporten via ons ondersteuningskanaal, ons Bug Bounty-programma en security@atlassian.com. Meer informatie is beschikbaar in ons Trust Center (https://www.atlassian.com/trust) over onze SLO's voor het oplossen van beveiligingsbugs (https://www.atlassian.com/trust/security/bug-fix-policy ).
Ons Atlassian-beveiligingsteam gebruikt meerdere methoden om kwetsbaarheden in zowel de interne als externe infrastructuur op te sporen. Jira-tickets worden aangemaakt voor opsporings- en hersteldoeleinden, en vervaldatums worden toegewezen volgens onze SLO op basis van zowel de ernst als de oorzaak van de kwetsbaarheid. We hebben een lopend proces om tickets voor geïdentificeerde kwetsbaarheden uit te vaardigen aan systeemeigenaren, en ons beveiligingsmanagementteam beoordeelt alle gerapporteerde kwetsbaarheden en zorgt ervoor dat er actie wordt ondernomen tegen deze kwetsbaarheden.
Meer informatie hierover is te vinden in onze speciale paper over Atlassian’s Approach to Vulnerability Management.
Meer informatie over onze aanpak van beveiligingstests is ook te vinden in ons Trust Center op: Approach to External Security Testing | Atlassian | Kwetsbaarheidsbeheer | Atlassian Trust Center
Beleid voor oplossen van beveiligingsbugs | Atlassian Trust Center
Benadering van externe beveiligingstests | Atlassian Trust Center
Benadering van kwetsbaarheidsbeheer | Atlassian Trust Center |
| 5.2 Beschermende monitoring | Atlassian heeft in antwoord op de behoefte om onze eigen aanpak voor incidentbeheer uit te breiden in de context van een steeds complexer bedreigingslandschap ons zogenoemde 'programma voor beveiligingsdetectie' geïntroduceerd. Detecties zijn zoekopdrachten die proactief worden uitgevoerd volgens een vast schema op het platform voor beveiligingsincidenten en gebeurtenisbeheer van Atlassian, om schadelijke activiteiten te ontdekken die gericht zijn op Atlassian en zijn klanten.
Ons Detectie en reactie-team is gericht op het regelmatig aanmaken van nieuwe detecties, het afstemmen en verbeteren van bestaande detecties en het automatiseren van detectieresponsen. Dit gebeurt in een aantal verschillende dimensies, waaronder producten, aanvalstypen en logbronnen om er zeker van te zijn dat onze detectie zo effectief en uitgebreid mogelijk is.
Het doel van dit programma is om er niet alleen zeker van te zijn dat we voorbereid zijn op de risico's waarmee we tegenwoordig te maken krijgen, maar ook om goed te anticiperen om en ons voor te bereiden op het dreigingslandschap van de toekomst. Ons Detectie en reactie-team heeft bovendien een tool ontwikkeld om de detecties die we aanmaken te standaardiseren, zodat we zeker zijn van een hoge mate van consistentie en kwaliteit voor de detecties die we uitvoeren. We geloven dat we hiermee een primeur binnen de branche hebben.
We hebben IDS geïmplementeerd op onze kantoorlocaties en in onze cloudhostingomgeving. Voor het Atlassian Cloud Platform kan het doorsturen van logs geïntegreerd worden met een platform voor beveiligingsanalyse. Belangrijke systeemlogboeken worden vanaf elk systeem doorgestuurd naar een gecentraliseerd logplatform, waar logboeken alleen gelezen kunnen worden. Het Beveiligingsteam van Atlassian maakt waarschuwingen aan op ons platform voor beveiligingsanalyses (Splunk) en controleert op tekenen van schade. Onze SRE-teams gebruiken het platform om te controleren op problemen met beschikbaarheid of prestaties. Logboeken worden 30 dagen bewaard in hete back-up en 365 dagen in koude back-up.
Ga voor meer informatie over ons detectieprogramma naar https://www.atlassian.com/trust/security/detections-program | Atlassian detectieprogramma | Atlassian Trust Center
Logboeken gebruiken | Atlassian Trust Center
Addendum voor gegevensverwerking | Atlassian Trust Center |
| 5.3 Incidentmanagement | Atlassian heeft een uitgebreide aanpak voor beveiligingsincidenten. Onder een beveiligingsincident valt voor ons elk geval waarbij de vertrouwelijkheid, integriteit of beschikbaarheid van klantgegevens, de gegevens van Atlassian of de services van Atlassian negatief beïnvloed worden.
We hebben een duidelijk gedefinieerd intern kader dat draaiboeken bevat voor verschillende soorten incidenten. Het kader omvat de stappen die we moeten zetten in elke fase van onze incidentrespons om er zeker van te zijn dat onze processen consistent, herhaalbaar en efficiënt zijn. Dit omvat dekking van incidentdetectie en -analyse en de categorisatie, inperking, uitroeiing en het herstel van incidenten. Deze consistentie wordt ondersteund door het gebruik van onze eigen producten, waaronder Confluence, Jira en Bitbucket, als onderdeel van onze incidentresponsprocessen:
- Confluence wordt gebruikt om onze responsprocessen op een centrale locatie te maken, te documenteren en bij te werken
- Jira wordt gebruikt om tickets aan te maken om de voortgang van het responsproces bij te houden voor (potentiële en daadwerkelijke) beveiligingsincidenten van begin tot eind
- Bitbucket wordt gebruikt in situaties waarin we oplossingen ontwikkelen op basis van code om te reageren op bepaalde uitzonderingsgevallen die zich voordoen binnen bepaalde incidenten
Uitgebreide en gecentraliseerde registratie en bewaking van onze producten en infrastructuur zijn ingesteld om er zeker van te zijn dat we potentiële incidenten snel ontdekken, ondersteund door een team van uiterst gekwalificeerde incidentmanagers op afroep die veel ervaring hebben met het coördineren van een effectieve respons. We hebben bovendien toegang tot een reeks externe experts die ons helpen zo effectief mogelijk te onderzoeken en reageren.
We hebben meldingspocessen voor klanten als hun gegevens betrokken zijn bij bevestigde incidenten, evenals een sterk beoordelingsproces voor na incidenten, zodat we kunnen leren van incidenten om onze werkwijzen te verbeteren en het werk van kwaadwillende partijen in de toekomst moeilijker te maken. Zie in ons Atlassian Trust Center onze aparte paper over Hoe wij het beheer van beveiligingsincidenten aanpakken voor meer informatie. | Incidentmanagement | Atlassian Trust Center
Addendum voor gegevensverwerking | Atlassian Trust Center |
| 5.4 Configuratie- en wijzigingsbeheer | Ons verandermanagementproces is een beetje anders dan een traditioneel proces. Traditionele verandermanagementprocessen zijn afhankelijk van een piramidevormige hiërarchie voor controle op veranderingen. Dat betekent dat, wanneer iemand een verandering wil doorvoeren, deze eerst moet worden voorgelegd aan een bestuur dat het uiteindelijk goed- of afkeurt.
We hebben een aanpak in open source-stijl omarmd die we 'Peer Review, Green Build' (PRGB) noemen. Het contrast met traditionele verandermanagementprocessen is dat elke verandering volgens de PRGB-aanpak, van codewijzigingen of aanpassingen in de infrastructuur, beoordeeld worden door minimaal één peer (collega) om eventuele problemen die door de verandering kunnen worden veroorzaakt te identificeren. We vergroten het aantal beoordelaars op basis van hoe kritisch de wijziging is of hoe kritisch de systemen zijn waar de verandering invloed op zal hebben, en we vertrouwen erop dat onze technici problemen vaststellen en ze rapporteren voordat de wijziging doorgevoerd wordt. Dit proces werkt goed om veranderingen in onze omgeving op een dynamische en aanpasbare manier te beheren. Het deel 'Green Build' van dit proces slaat op een succesvolle of schone build in onze CI/CD waarin nieuwe wijzigingen zijn opgenomen. Als de wijziging componenten introduceert die de tests van de integratie, functie, unit of beveiliging niet doorstaan, wordt de build afgewezen en blijft het oorspronkelijke wijzigingsverzoek staan om issues aan te pakken.
Onze benadering van het gebruik van 'quality assistance' (in plaats van gebruikelijke 'quality assurance') is iets waar we enthousiast over zijn: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance | Veranderingen in onze omgeving beheren | Atlassian Trust Center
Overstappen van quality assurance naar quality assistance |
| Principe 6: Personeelsbeveiliging |
| | Bedrijfswaarden
Informatie over de bedrijfswaarden van Atlassian is hier beschikbaar: https://www.atlassian.com/company/values
| Bedrijfswaarden
Bedrijfswaarden | Atlassian
|
| Antecedentenonderzoeken van werknemers
Wereldwijd worden nieuwe Atlassians verplicht om een antecedentenonderzoek te ondergaan. Bij nieuwe werknemers als gevolg van een acquisitie wordt na de acquisitiedatum een antecedentenonderzoek uitgevoerd. Bij alle nieuwe werknemers en onafhankelijke contractanten wordt een strafrechtelijke controle uitgevoerd. Er worden ook opleidingsverificatie, tewerkstellingsverificatie of kredietcontroles toegevoegd als de functie of het niveau van de functie dat vereist. We voeren volledige antecedentenonderzoeken uit voor leidinggevende en boekhoudkundige functies. | Antecedentenonderzoeken van werknemers
Antecedentenonderzoeken | Atlassian Trust Center |
| Beveiligingstraining voor alle Atlassian-werknemers
Atlassian biedt informatiebeveiligingstrainingen als onderdeel van een onboardingtraining ('dag 1') voor nieuwe starters en doorlopend voor al het personeel.
Naast deze algemene informatiebeveiligingstraining worden onze ontwikkelaars gerichter getraind op het gebied van veilig coderen. Deze wordt ondersteund door ons programma voor geïntegreerde beveiligingsingenieurs.
We geven ook doorlopende actuele trainingen over malware, phishing en andere beveiligingsproblemen. Veiligheidsbewustzijn | Atlassian Trust Center | Beveiligingstraining voor alle Atlassian-werknemers
Veiligheidsbewustzijn | Atlassian Trust Center |
| Principe 7: Veilige ontwikkeling | Atlassian hanteert veilige ontwikkelingsmethoden in alle fasen van de ontwikkelingscyclus. Bekijk https://www.atlassian.com/trust/security/security-in-development voor meer informatie.
Tijdens de ontwerpfase worden praktijken als dreigingsmodellering, ontwerpbeoordeling en onze regelmatig bijgewerkte bibliotheek met beveiligingsnormen ingezet. Deze zorgen ervoor dat er rekening wordt gehouden met de juiste beveiligingsvereisten.
Tijdens de ontwikkeling vertrouwen we op een verplicht peer review-proces als eerste lijn van beveiligingsbeoordeling. Dit proces wordt ondersteund door geautomatiseerde statische analysecontroles (SAST) en handmatige beveiligingstests (zowel door interne teams als externe experts, zoals bepaald door ons risicobeoordelingsproces). De ontwikkeling wordt ook ondersteund door trainingsprogramma's voor applicatiebeveiliging en een kennisdatabase voor beveiliging die wordt onderhouden door het beveiligingsteam.
Formele operationele gereedheid en veranderingscontroleprocessen zorgen er vervolgens voor dat alleen goedgekeurde wijzigingen in productie worden geïmplementeerd. Na de implementatie maken we regelmatig gebruik van geautomatiseerde scans van kwetsbaarheden en een toonaangevend bug bounty-programma (het bug bounty-programma van Atlassian | Bugcrowd ) om continue zekerheid van onze toepassingen te bieden.
Daarnaast kun je het SOC 2-rapport van Atlassian bekijken. Dit rapport is gericht op het evalueren van de informatiesystemen van een organisatie die relevant zijn voor beveiliging, beschikbaarheid, verwerkingsintegriteit, vertrouwelijkheid en privacy. | Addendum voor gegevensverwerking | Atlassian Trust Center |
| Principe 8: Beveiliging van de supply chain | Als Atlassian externe leveranciers inschakelt (waaronder contractors en cloudserviceproviders) zorgen we dat we er zeker van zijn dat die samenwerkingen onze klanten of hun gegevens op geen enkele manier in gevaar brengen. Om dit te bereiken voeren onze juridische teams en inkoopteams een beoordelingsproces uit voor elke voorgestelde samenwerking met externe leveranciers. Samenwerkingen waarvan we vinden dat ze een hoog of kritiek risico opleveren, worden onderworpen aan extra beoordelingen door onze beveiligings-, risico- en complianceteams. Bovendien voeren we doorlopende due diligence uit via latere beoordelingen, ofwel door contractverlenging ofwel jaarlijks, afhankelijk van het risiconiveau van de samenwerking.
Atlassian eist ook van leveranciers dat ze voldoen aan minimale beveiligingsvereisten als onderdeel van hun samenwerking met ons. Deze worden afgedwongen door ze op te nemen in onze leverancierscontracten. Deze vereisten zijn afhankelijk van het risiconiveau van de samenwerking en omvatten het volgende:
- SAML-integratie met het single sign-on-platform van Atlassian
- Versleuteling voor gegevens in transit en bij rust met niet-verouderde algoritmes
- Voldoende logboekmechanismen hebben om Atlassian relevante informatie te bieden over potentiële beveiligingsincidenten
| Risicobeheer voor leveranciers | Atlassian Trust Center
Atlassian SOC 2 | Pagina 29 (Leveranciersbeheer) |
| Principe 9: Veilig gebruikersbeheer |
| 9.1 Authenticatie van gebruikers voor beheerinterfaces en ondersteuningskanalen | Hier bij Atlassian geloven we dat dit een gedeelde verantwoordelijkheid is voor zowel de klant als Atlassian.
Geverifieerde gebruikers
We behandelen alle klantgegevens als even gevoelig en we hebben strenge controles geïmplementeerd voor deze gegevens. Onze interne werknemers en contractors krijgen bewustwordingstraining tijdens het onboardingproces. Hierin wordt het belang van en best practices voor omgang met klantgegevens behandeld.
Alleen geautoriseerde Atlassians hebben binnen Atlassian toegang tot de klantgegevens die opgeslagen zijn in onze applicaties. Authenticatie vindt plaats via openbare codes die met individuele wachtwoorden beschermd zijn, en servers staan alleen binnenkomende SSH-verbindingen toe van Atlassian en interne datacenter-locaties. Alle toegang is beperkt tot groepen die gemachtigd zijn, tenzij toegang wordt aangevraagd en de aanvraag wordt goedgekeurd. Hiervoor is aanvullende authenticatie met 2FA vereist.
Ons internationale supportteam maakt onderhouds- en supportprocessen mogelijk met strenge authenticatie- en autorisatiecontroles. Toegang tot gehoste applicaties en gegevens wordt mogelijk gemaakt om gezondheidscontroles en onderhoudswerkzaamheden aan systemen of applicaties uit te voeren, of op aanvraag van de klant via ons supportsysteem. Onze klanten krijgen ook opties om expliciete toestemming te geven aan supportmedewerkers die zij geschikt achten om toegang te krijgen tot hun gegevens via onze toestemmingscontrolechecker.
Ongeautoriseerde of ongepaste toegang tot klantgegevens wordt gezien als een beveiligingsincident en wordt afgehandeld volgens ons proces voor incidentmanagement. Dit proces omvat instructies voor het op de hoogte brengen van betrokken klanten als er sprake is van een beleidsschending. | Toegang tot klantgegevens beheren | Atlassian Trust Center
Addendum voor gegevensverwerking | Atlassian Trust Center |
| 9.2 Scheidings- en toegangscontrole binnen beheerinterfaces | Met deze AWS-architectuur hosten we een aantal platform- en productservices die in onze oplossingen worden gebruikt. Dit omvat platformmogelijkheden die worden gedeeld en gebruikt voor meerdere Atlassian-producten, zoals Media, Identity en Commerce, ervaringen zoals onze Editor en productspecifieke mogelijkheden, zoals de Jira Issue-service en Confluence Analyses.
Atlassian-ontwikkelaars leveren deze services via een intern ontwikkeld platform-as-a-service (PaaS), Micros genaamd, dat automatisch de implementatie van gedeelde services, infrastructuur, gegevensopslag en hun beheermogelijkheden orkestreert, inclusief beveiligings- en compliance-controlevereisten (zie figuur 1 hierboven). Een Atlassian-product bestaat doorgaans uit meerdere "containerservices" die op AWS worden geïmplementeerd met behulp van Micros. Atlassian-producten maken gebruik van kernplatformmogelijkheden (zie figuur 2 hieronder) die variëren van verzoekroutering tot binaire objectopslag, verificatie/autorisatie, transactionele door gebruikers gegenereerde inhoud (UGC) en entiteitsrelaties, datameren, gemeenschappelijke logboekregistratie, verzoektracering, waarneembaarheid en analytische services.
Naast onze cloudinfrastructuur hebben we een multi-tenant microservices-architectuur opgezet met een gedeeld platform dat onze producten ondersteunt. In een multi-tenantarchitectuur bedient één enkele service meerdere organisaties, waaronder de databases en computerinstallaties die nodig zijn om onze cloudproducten te kunnen draaien. Elke scherf (in wezen een container – zie figuur 3 hieronder) bevat de gegevens voor meerdere huurders, maar de gegevens van elke huurder zijn geïsoleerd en ontoegankelijk voor andere huurders. Het is belangrijk op te merken dat we geen single-tenantarchitectuur aanbieden.
Ga voor meer informatie naar https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure | Architectuur voor meerdere tenants | Atlassian Cloud-architectuur en operationele praktijken
Addendum voor gegevensverwerking | Atlassian Trust Center |
| Principe 10: Identiteit en authenticatie |
| | Raadpleeg 9.1 en 9.2 voor meer informatie over authenticatie en toegangsbeheer. | n.v.t. |
| Principe 11: Bescherming van de externe interface |
| | Raadpleeg Principe 5 voor meer informatie over hoe Atlassian Trust onze cloudklanten beschermt. | n.v.t. |
| Principe 12: Veilig servicebeheer |
| | In het Addendum voor gegevensverwerking van Atlassian doen we toezeggingen om klantgegevens te beschermen, waaronder toegangscontrole en privilegebeheer.
Raadpleeg 9.1 en 9.2 voor meer informatie over authenticatie en toegangsbeheer. | n.v.t. |
| Principe 13: Auditinformatie voor gebruikers |
| | Alle toegang tot de klanttoepassing wordt geregistreerd. Elke interactie met de gebruikersinterface wordt geregistreerd in de auditlog van de toepassing.
Atlassian beperkt, registreert en controleert bevoorrechte toegang tot het identiteitsarchief van ons Atlassian-account en andere beheersystemen voor informatiebeveiliging.
Logs worden opgeslagen in een logisch gescheiden systeem en schrijftoegang tot de logs is beperkt tot leden van het beveiligingsteam. Waarschuwingen worden naar het beveiligingsteam of de servicedesk gestuurd wanneer er bepaalde acties of gebeurtenissen in de logs worden geïdentificeerd. Onze centrale logservice (voor het Atlassian Cloud Platform, JIRA, Confluence en Bamboo) is geïntegreerd met onze infrastructuur voor beveiligingsanalyses voor geautomatiseerde analyses en maakt waarschuwingen aan om mogelijke problemen te identificeren.
Voor Bitbucket worden auditlogboeken gebruikt voor onderzoek na een incident. Door Puppet beheerde serviceconfiguratie, als declaratief configuratieformaat, zorgt ervoor dat alle systeemconfiguraties die worden beheerd op basis van de manifesten bij elke run juist geconfigureerd worden. Er zijn bewakingsmeldingen van kracht als Puppet niet werkt op een bepaalde server. Onze interne en externe kwetsbaarheidsscanners waarschuwen onder meer voor onverwachte open poorten of andere wijzigingen in de configuratie (bijvoorbeeld TLS-profielen van luisterservers).
Raadpleeg Atlassian Access voor meer informatie: Atlassian Access | Beveiliging en SSO voor Jira, Confluence, enz.
Intern voor Atlassian worden logboeken opgeslagen in een logisch gescheiden systeem en de schrijftoegang tot de logboeken is beperkt tot leden van het beveiligingsteam en ons waarnemingsteam. Onze centrale logboekservice is geïntegreerd met onze infrastructuur voor beveiligingsanalyses voor geautomatiseerde analyses en er worden waarschuwingen aangemaakt om mogelijke problemen te identificeren.
Voor klanten van Atlassian Cloud zijn auditlogboeken voor veranderingen in de organisatie beschikbaar als onderdeel van Atlassian Access. Met auditlogboeken heb je inzicht in beheerdersacties voor gebruikers, groepen, machtigingen, enz. Meer informatie is hier te vinden: https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/
Cloudproducten van Atlassian hebben ook hun eigen auditlogboeken voor productspecifieke veranderingen. | n.v.t. |
| Principe 14: Veilig gebruik van de dienst |
| | Hier bij Atlassian geloven we dat dit een gedeelde verantwoordelijkheid is tussen zowel de klant als Atlassian.
Er zijn allerlei andere resources waar we in deze paper naar verwezen hebben of die je anderszins kan raadplegen voor meer informatie over onze aanpak van kwetsbaarheidsmanagement en beveiliging in het algemeen.
| n.v.t. |