Säkerhetsarbete i Atlassian Cloud: mer än standardinställningar

Atlassian Cloud är en mogen, välbyggd plattform med en solid säkerhetsgrund. Men “solid grund” och “säker miljö” är inte samma sak. Standardinställningarna är designade för att fungera för de flesta, inte för att passa er organisation specifikt.

Det är skillnaden som avgör om ni har kontroll eller bara tror att ni har det.

Fallgropen med “det fungerar ju”

Det vanligaste säkerhetsmisset vi ser i Atlassian Cloud-miljöer är inte en teknisk brist. Det är istället att ingen har ägnat en timme åt att fråga: vad kan en vanlig medarbetare faktiskt göra i vår miljö?

Svaret överraskar ofta. Standardkonfigurationer i Jira och Confluence tillåter i många fall:

• Att vem som helst i organisationen kan skapa nya projekt och spaces
• Att externa gäster kan bjudas in utan administratörsgodkännande
• Att sidor och ärenden kan delas publikt utan varning
• Att appar installeras utan central granskning

Inget av detta är en bugg. Det är features som ni behöver göra ett aktivt val kring.

Atlassian Guard: plattformens säkerhetslager

Atlassian Guard (tidigare Atlassian Access) är den centrala produkten för organisationer som behöver mer kontroll än standardinställningarna ger. Det ger er:

Identitets- och åtkomsthantering SSO via SAML 2.0 kopplar Atlassian Cloud till er befintliga identitetsprovider (Azure AD, Okta, Google Workspace m.fl.). SCIM-provisioning innebär att konton skapas och inaktiveras automatiskt när medarbetare börjar eller slutar. Resultatet är ingen manuell hantering och inga inaktiva konton som glöms bort.

Tvåfaktorsautentisering på organisationsnivå Med Guard kan ni kräva MFA för alla hanterade konton. Det är inte en rekommendation utan ett krav. Det gäller även om en medarbetare försöker logga in från en ny enhet eller plats.

Datasäkerhetspolicyer Definiera vilka åtgärder som är tillåtna per användargrupp: kan mobila enheter exportera data? Kan externa användare ladda ner bilagor? Hur länge är inaktiva sessioner tillåtna? Dessa policyer sätts centralt och gäller automatiskt.

Granskningsloggar Guard ger detaljerade loggar över vem som gjort vad, när och varifrån. Avgörande för compliance-revisioner och för att förstå vad som faktiskt hände om något går fel.

Principen om minsta behörighet i praktiken

“Minsta behörighet” är ett välkänt begrepp men sällan implementerat. I Atlassian Cloud innebär det konkret:

Jira: Gå igenom era projektbehörigheter. Standardschemat är ofta bredare än nödvändigt. Avgörande fråga: kan en medarbetare utanför teamet se, ändra eller stänga ärenden de inte bör ha tillgång till?

Confluence: Sätt tydliga standardbehörigheter på space-nivå. Öppna spaces är bra för intern transparens, men känsliga avdelningsspaces (HR, Legal, Finance) ska aldrig ha öppna läsbehörigheter som standard.

Administratörsrollen: Hur många i er organisation har Global Admin? Det bör vara färre än ni tror är rimligt. Separera Jira-admin från Confluence-admin och begränsa Atlassian Admin till ett fåtal betrodda konton.

Appar och tillägg: det förbisedda angreppssättet

Varje app ni installerar från Atlassian Marketplace är en tredjepartsaktör med tillgång till er data. Många organisationer installerar appar snabbt och tar bort dem sällan.

Gå igenom er applista med tre frågor:

1. Används den här appen aktivt?
2. Vilken data har den tillgång till?
3. Har leverantören tecknat ett personuppgiftsbiträdesavtal (DPA)?

Den sista frågan är viktig inför migrering och för löpande compliance. Atlassians Marketplace App Trust-program hjälper er identifiera leverantörer som uppfyller höga integritetsstandarder, men det ersätter inte en egen granskning.

Om ni hanterar extra känslig data och vill gå längre: läs vår genomgång av BYOK i Atlassian Cloud, som ger er möjligheten att hantera era egna krypteringsnycklar.

Löpande rutiner, inte engångsinsatser

Säkerhet i Atlassian Cloud är inte ett projekt att avsluta. Det är en löpande rutin. Konkret innebär det:

• Kvartalsvis: Gå igenom inaktiva användarkonton och externa gäster
• Halvårsvis: Granska projektbehörigheter och space-åtkomster i Confluence
• Vid varje ny app: DPA-kontroll och behörighetsgranskning innan installation
• Vid personalavgång: Verifiera att SCIM har inaktiverat alla konton korrekt

De organisationer som lyckas bäst behandlar dessa rutiner som en del av förvaltningen, inte som ett säkerhetsinitiativ som körs en gång.

Var börjar ni?

En genomgång av er Atlassian Cloud-miljö behöver inte vara ett stort projekt. Börja med dessa tre frågor:

1. Har ni SSO aktiverat via Atlassian Guard?
2. Vet ni hur många aktiva externa gäster ni har i Confluence just nu?
3. Har alla appar i er miljö ett godkänt DPA?

Om svaret på någon av dessa är nej eller “vet inte”, är det en bra startpunkt.

Findr hjälper er kartlägga er nuläge och bygga en säkerhetsmodell som faktiskt håller när organisationen skalas. Läs mer om hur vi hjälper er komma rätt från start eller kontakta oss direkt för en förutsättningslös genomgång.