En nybörjarguide till Atlassian Access

Därför får du i den här bloggen ett datablad för Access. Nedan hittar du alla termer och definitioner du behöver känna till när du arbetar med det.

Vad är Atlassian Access?

Det är en prenumeration på flera sammankopplade inställningar, paketerade som en prenumeration på ”Atlassian Access”. Det räknas inte som en applikation på samma sätt som Jira och Confluence. Det är viktigt att förstå skillnaden tidigt för att förstå hur Access används.

Vad gör Access?

Det gör det möjligt för Atlassian-kunder att tillämpa säkerhetsinställningar och SSO (single sign-on) samt upprätthålla användarpolicyer i sina Atlassian Cloud-produkter.

Vilka Atlassian-produkter fungerar Access med?

• Jira Software

• Jira Service Management

• Jira Work Management

• Confluence

• Bitbucket

• Trello

• Statuspage

Obs! Access fungerar inte med Data Center- eller Server-produkter.

Vilka funktioner har det?

• SAML single sign-on (kräver en SAML 2.0-identitetsleverantör som Azure AD, Okta, Google Workspace eller Identity One)

• Användarprovisionering (SCIM) (kräver Azure AD, Okta eller Google Workspace)

• Granskningslogg för organisationen

• Kontroller för API-token

• Obligatorisk tvåstegsverifiering

• Hantering av sessionslängd

• Produktidentifiering

När rekommenderas Access?

• När centralt hanterade Atlassian-användarkonton behövs. Utan Access ansvarar varje användare för att hantera sitt eget konto.

• När du vill erbjuda single sign-on och automatiserad användarprovisionering med SCIM. Det blir vanligtvis mer värdefullt när ni har fler än 250 användare.

• När användare vill ansluta sina Cloud-appar till en extern identitetsleverantör som inte är Google Workspace.

• När du behöver tillämpa användarpolicyer i dina Atlassian Cloud-appar, till exempel lösenordskrav, tvåstegsverifiering och liknande. Kunder har ofta säkerhetspolicyer som kräver en viss minsta lösenordslängd.

Hur konfigureras Access?

Atlassian-konton eller ID:n – För att kunna använda en Atlassian Cloud-produkt behöver varje användare ha ett Atlassian-ID eller -konto, som är unikt och vanligtvis kopplat till en företagsdomän. Till exempel ”amccallum@amazingaccess.com”.

Domänverifiering – Genom att använda Access meddelar kunden Atlassian att dessa konton ska hanteras direkt av kunden. För att göra detta behöver kunder göra anspråk på och verifiera relevanta domäner genom denna process.

Obs! Detta kräver samordning med kundens IT-avdelning.

Hanterade konton – När domänverifieringen är klar omfattar de domäner som kunden har gjort anspråk på alla användarkonton. I detta fall kan ”@amazingaccess.com” hanteras av kunden och omfattas av ”Managed Accounts”.

Obs! Organisationsadministratören kan också inaktivera hanterade användare, vilket tar bort deras åtkomst till alla Cloud-produkter och system som använder Atlassian-konton.

Licensiering – Licensmåttet för Access är antalet ”Billable Accounts”.

Billable Account – Alla hanterade konton som har åtkomst till Jira Software, Jira Work Management, Confluence, Bitbucket, Jira Service Management (endast agenter) eller Trello. När en användare har åtkomst till NÅGON av dessa produkter räknas den som fakturerbar, vilket innebär att du behöver betala för en Access-användarlicens. Om en användare har flera Atlassian-produkter (Jira Software, Confluence, Bitbucket osv.) behöver du bara betala en Access-licens för den användaren.

Prissättning – Precis som andra Cloud-produkter kan Access köpas per användare och månad eller i användarnivåer. Använd den här priskalkylatorn för hjälp. Undantaget är Atlassian Enterprise Cloud, där Access ingår i Enterprise-prenumerationen.

Organisationer, webbplatser och Cloud-produkter – För att kunna använda Access är det viktigt att förstå hur Atlassian Cloud-produkter är strukturerade. Access är i praktiken en företagsomfattande prenumeration som gäller för alla Atlassian-webbplatser och -produkter inom en organisation.

Obs! Med organisation menar vi en ”Atlassian Organisation”, som är ett virtuellt skal som innehåller Atlassian-produkter.

Inom en Atlassian Organisation kan en kund ha en eller flera Cloud-webbplatser. Varje webbplats kan innehålla ett antal Atlassian-produkter. Större Atlassian Enterprise-kunder kan ha flera Atlassian Organisationer inom företaget.

Vad kunder behöver betala för – Som nämnts tidigare består Access i huvudsak av tjänster som hänger ihop. Licensen och kostnaden beror på vad du vill göra och vilka Atlassian-produkter medarbetarna i kundens företag använder. Kunder behöver bara betala för användare när de tillämpar säkerhetsinställningar via autentiseringspolicyer.

Hanterade konton – En kund kan verifiera en domän, skapa hanterade konton och utan kostnad visa eller uppdatera konton för hanterade användare. De hanterade kontona blir fakturerbara användare när kunden börjar tillämpa säkerhetsinställningar, till exempel Access-funktionen autentiseringspolicyer.

Atlassian Access-testversion – Atlassian erbjuder en kostnadsfri 30-dagars testversion av Access. Clearvision (nu en del av Eficode) kan ge en offert för en fullständig prenumeration som börjar gälla när testperioden är slut. Om kunden inte köper en prenumeration efter testperiodens slut avslutas prenumerationen på Atlassian Access.

Följande ändringar sker:

• Hanterade användare kommer inte längre att logga in med SAML single sign-on. I stället loggar de in med sitt Atlassian-konto. Vissa användare kan behöva ange ett nytt lösenord för sitt Atlassian-konto.

• Tvåstegsverifiering kommer inte längre att tillämpas, så hanterade användare kan välja att inaktivera den för sitt Atlassian-konto.

Organisationen och de verifierade domänerna påverkas inte när prenumerationen avslutas. Organisationsadministratörens möjlighet att visa och uppdatera Atlassian-konton för sina hanterade användare påverkas inte heller.

Autentiseringspolicyer – I Access kan kunder med autentiseringspolicyer ange autentiseringsinställningar för olika användare. De kan till exempel ha användargrupper med olika säkerhetskrav, såsom anställda, partner och konsulter.

Tillgängliga autentiseringspolicyer i Access:

1. Icke-fakturerbar – Skapa en icke-fakturerbar policy när du inte vill betala för vissa användare.
   Du kan bara ange en icke-fakturerbar policy som standardpolicy i den lokala katalogen. Du kan inte ha en icke-fakturerbar policy om du använder användarprovisionering (SCIM).

2. Lokal katalog – Innehåller medlemmar som du inte hanterar i din identitetsleverantör. Du bjuder in dem eller så registrerar de sig själva.

3. Tvåstegsverifiering – Kräv ett andra steg vid inloggning, eller gör det valfritt för medlemmar.

4. Lösenordskrav – Ange krav för lägsta lösenordsstyrka och lösenordets giltighetstid.

5. Inaktiv sessionstid – Ange hur länge medlemmar kan vara inaktiva innan de loggas ut.

6. Medlemmar – Visar antalet medlemmar i en policy. Lägg till eller flytta medlemmar från en policy till en annan.

7. Single sign-on (SSO) – Ange när du kräver inloggning till Atlassian via SAML eller Google Workspace SSO. Du kan endast kräva SSO i en katalog för identitetsleverantörer.

8. Katalog för identitetsleverantörer – Innehåller medlemmar som du synkroniserar eller autentiserar via din identitetsleverantör. Du kan lägga till och flytta medlemmar mellan autentiseringspolicyer.

9. Du kan endast ange en icke-fakturerbar policy som standardpolicy i den lokala katalogen.

10. Du kan inte ha en icke-fakturerbar policy om du använder användarprovisionering (SCIM).

Obs! Kunder kan skapa upp till 20 autentiseringspolicyer per organisation.

Product Discovery – När kunder verifierar en domän kan de se hur många hanterade konton som finns i deras organisation. Det är vanligt att kunder upptäcker oväntade användare från en annan webbplats, en annan del av verksamheten eller medarbetare som helt enkelt har skapat och använder kostnadsfria Trello-konton. Om en användares Atlassian-konto använder den domän som de har verifierat blir det ett hanterat konto.

Icke-fakturerbar policy – Kunder kan tillämpa en icke-fakturerbar policy om de vill undanta användare från sin Access-prenumeration. Det finns dock vissa begränsningar eftersom vissa Access-funktioner inte tillåter icke-fakturerbara policyer, och endast EN icke-fakturerbar policy är tillåten.

Kunder kan inte heller:

• Kräva single sign-on för användare i den icke-fakturerbara policyn.

• Kräva tvåstegsverifiering för användare i den icke-fakturerbara policyn.

• Lägga till användare som synkroniseras från deras identitetsleverantör (Okta, Azure AD, G Suite) i policyn.

Access-funktioner och icke-fakturerbara policyer

Den här tabellen förklarar hur viktiga Access-funktioner fungerar i förhållande till icke-fakturerbara policyer.

* Alla Atlassian-användarkonton för den registrerade domänen (t.ex. amazingaccess.com).

Vanliga kundfrågor

• Någon annan i vår verksamhet har registrerat vår företagsdomän (t.ex. acme.com). Kan vi använda Access och Single Sign-on?

• NEJ, eftersom en domän endast kan registreras av en Atlassian Access-organisation/prenumeration. Kunden behöver samordna sig med sina kollegor för att ha en gemensam Atlassian Access-organisation/prenumeration för verksamheten.

• NEJ, eftersom en domän endast kan registreras av en Atlassian Access-organisation/prenumeration.

• Kunden behöver samordna sig med sina kollegor för att ha en gemensam Atlassian Access-organisation/prenumeration för verksamheten.

• Kan vi ha flera Jira- eller Confluence-instanser som hanteras av vår Atlassian Access-prenumeration?

• JA. En Atlassian Access-organisation kan ha stöd för flera Atlassian-produkter, även flera webbplatser för samma produkt, som Jira eller Confluence.

• Vi har massor av kostnadsfria Trello-konton. Kan jag exkludera dem från Atlassian Access?

• JA. Du kan definiera EN säkerhetspolicy för ”ej fakturerbara” konton, som exkluderar berörda konton från Atlassian Access-prenumerationen, policyer och SAML-baserad enkel inloggning.

• JA. Du kan definiera EN säkerhetspolicy för ”ej fakturerbara” konton, som exkluderar berörda konton från Atlassian Access-prenumerationen, policyer och SAML-baserad enkel inloggning.

• Vi använder GSuite och Google-konton för att logga in. Behöver vi fortfarande Atlassian Access?

• NEJ. Du kan använda GSuite och Google-inloggning utan kostnad. GSuite-konton och -domäner synkroniseras utan kostnad och kräver inte Atlassian Access. Kunder kan köpa Access för förbättrad säkerhet och samordning.

• NEJ. Du kan använda GSuite och Google-inloggning utan kostnad.

• GSuite-konton och -domäner synkroniseras utan kostnad och kräver inte Atlassian Access.

• Kunder kan köpa Access för förbättrad säkerhet och samordning.