Einsteiger-Datenblatt zu Atlassian Access

Deshalb stellen wir euch in diesem Blog einen Spickzettel für Access zur Verfügung. Im Folgenden findet ihr alle Begriffe und Definitionen, die ihr für die Arbeit damit kennen solltet.

Was ist Atlassian Access?

Es handelt sich um ein Abonnement für mehrere miteinander verknüpfte Einstellungen, die als „Atlassian Access“-Abonnement gebündelt sind. Es gilt nicht als Anwendung im gleichen Sinne wie Jira und Confluence. Es ist wichtig, diesen Unterschied frühzeitig zu verstehen, um nachzuvollziehen, wie Access eingesetzt wird.

Was kann Access?

Es ermöglicht Atlassian-Kunden, Sicherheitseinstellungen und SSO (Single Sign-on) für ihre Atlassian-Cloud-Produkte anzuwenden und Benutzerrichtlinien durchzusetzen.

Mit welchen Atlassian-Produkten funktioniert Access?

• Jira Software

• Jira Service Management

• Jira Work Management

• Confluence

• Bitbucket

• Trello

• Statuspage

Hinweis: Access funktioniert nicht mit Data-Center- oder Server-Produkten.

Welche Funktionen bietet es?

• SAML Single Sign-on (erfordert einen SAML-2.0-Identity-Provider wie Azure AD, Okta, Google Workspace oder Identity One)

• Benutzerbereitstellung (SCIM) (erfordert Azure AD, Okta oder Google Workspace)

• Audit-Protokoll der Organisation

• Kontrollen für API-Tokens

• Erzwungene Bestätigung in zwei Schritten

• Verwaltung der Sitzungsdauer

• Produkterkennung

Wann wird Access empfohlen?

• Wenn zentral verwaltete Atlassian-Benutzerkonten erforderlich sind. Ohne Access ist jeder Benutzer selbst für die Verwaltung seines individuellen Kontos verantwortlich.

• Wenn ihr Single Sign-on und die automatisierte Benutzerbereitstellung über SCIM anbieten möchtet. Der Nutzen steigt in der Regel bei mehr als 250 Benutzern deutlich.

• Wenn Nutzer ihre Cloud-Apps mit einem externen Identity Provider verbinden möchten, der nicht Google Workspace ist.

• Wenn ihr Nutzerrichtlinien für eure Atlassian Cloud-Apps durchsetzen müsst, etwa Passwortanforderungen, Zwei-Faktor-Authentifizierung usw. Kunden haben häufig Sicherheitsrichtlinien, die beispielsweise eine Mindestlänge für Passwörter vorgeben.

Wie wird Access eingerichtet?

Atlassian Accounts oder IDs – Um ein Atlassian Cloud-Produkt nutzen zu können, benötigt jeder Nutzer eine eindeutige Atlassian ID bzw. einen Atlassian Account, der in der Regel mit einer Unternehmensdomain verknüpft ist. Zum Beispiel „amccallum@amazingaccess.com“.

Domain-Verifizierung – Mit Access teilt der Kunde Atlassian mit, dass diese Accounts direkt vom Kunden verwaltet werden. Dazu müssen Kunden die relevanten Domains über diesen Prozess beanspruchen und verifizieren.

Hinweis: Dafür ist eine Abstimmung mit der IT-Abteilung des Kunden erforderlich.

Verwaltete Accounts – Sobald die Domain-Verifizierung abgeschlossen ist, werden alle Nutzer-Accounts mit diesen beanspruchten Domains verknüpft. In diesem Fall kann „@amazingaccess.com“ vom Kunden verwaltet werden und fällt unter „Verwaltete Accounts“.

Hinweis: Der Organisationsadministrator kann auch verwaltete Nutzer deaktivieren und ihnen dadurch den Zugriff auf alle Cloud-Produkte sowie auf sämtliche Systeme entziehen, die Atlassian Accounts verwenden.

Lizenzierung – Die Lizenzmetrik für Access ist die Anzahl eurer „abrechenbaren Accounts“.

Abrechenbarer Account – Jeder verwaltete Account mit Zugriff auf Jira Software, Jira Work Management, Confluence, Bitbucket, Jira Service Management (nur Agents) oder Trello. Sobald ein Nutzer Zugriff auf EINES dieser Produkte hat, gilt er als abrechenbar. Das bedeutet, dass ihr für ihn eine Access-Nutzerlizenz benötigt. Wenn ein Nutzer mehrere Atlassian Produkte verwendet (Jira Software, Confluence, Bitbucket usw.), benötigt ihr nur eine Access-Lizenz für ihn.

Preise – Wie andere Cloud-Produkte kann Access monatlich pro Nutzer oder nach Nutzerstaffeln erworben werden. Dieser Preisrechner hilft euch weiter. Eine Ausnahme bildet Atlassian Enterprise Cloud: Access ist dort im Enterprise-Abonnement enthalten.

Organisationen, Sites und Cloud-Produkte – Um Access nutzen zu können, ist es wichtig zu verstehen, wie Atlassian Cloud-Produkte aufgebaut sind. Access ist im Grunde ein unternehmensweites Abonnement, das für alle Atlassian Sites und Produkte innerhalb einer Organisation gilt.

Hinweis: Mit Organisation ist hier eine „Atlassian Organisation“ gemeint – eine virtuelle Klammer, die Atlassian Produkte umfasst.

Innerhalb einer Atlassian Organisation kann ein Kunde eine oder mehrere Cloud-Sites haben. Jede Site kann mehrere Atlassian Produkte enthalten. Größere Atlassian Enterprise-Kunden können innerhalb ihres Unternehmens mehrere Atlassian Organisationen haben.

Wofür Kunden bezahlen müssen – Wie bereits erwähnt, besteht Access im Wesentlichen aus gekoppelten Services. Die Lizenz und die Kosten hängen davon ab, was ihr tun möchtet und welche Atlassian Produkte die Mitarbeiter im Unternehmen des Kunden nutzen. Kunden müssen nur für Nutzer bezahlen, auf die sie über Authentifizierungsrichtlinien Sicherheitseinstellungen anwenden.

Verwaltete Accounts – Ein Kunde kann kostenlos eine Domain verifizieren, verwaltete Accounts erstellen sowie Accounts verwalteter Nutzer anzeigen und aktualisieren. Verwaltete Accounts werden zu abrechenbaren Nutzern, sobald Kunden Sicherheitseinstellungen anwenden, also Access-Funktionen wie Authentifizierungsrichtlinien.

Atlassian Access-Testversion – Atlassian bietet eine kostenlose 30-tägige Testversion für Access an. Clearvision (jetzt Teil von Eficode) kann ein Angebot für ein vollständiges Abonnement erstellen, das nach Ablauf der Testversion beginnt. Wird es nach Ende der Testversion nicht erworben, wird der Kunde von Atlassian Access abgemeldet.

Die folgenden Änderungen treten ein:

• Verwaltete Nutzer melden sich nicht mehr über SAML Single Sign-on an. Stattdessen melden sie sich mit ihrem Atlassian Account an. Einige Nutzer müssen möglicherweise ein neues Passwort für ihren Atlassian Account festlegen.

• Die Zwei-Faktor-Authentifizierung wird nicht mehr erzwungen. Verwaltete Nutzer können sie daher für ihren Atlassian Account deaktivieren.

Die Organisation und die verifizierten Domains bleiben von der Abmeldung unberührt. Auch die Möglichkeit des Organisationsadministrators, die Atlassian Accounts seiner verwalteten Nutzer anzuzeigen und zu aktualisieren, bleibt unverändert.

Authentifizierungsrichtlinien – Mit Authentifizierungsrichtlinien in Access können Kunden die Authentifizierungseinstellungen für verschiedene Nutzer festlegen. Möglicherweise haben sie Nutzergruppen mit unterschiedlichen Sicherheitsanforderungen, etwa Mitarbeiter, Partner und Auftragnehmer.

Verfügbare Authentifizierungsrichtlinien in Access:

1. Nicht abrechenbar – Erstellt eine nicht abrechenbare Richtlinie, wenn ihr für bestimmte Nutzer nicht bezahlen möchtet.
   Eine nicht abrechenbare Richtlinie kann nur im lokalen Verzeichnis als Standardrichtlinie festgelegt werden. Bei Verwendung von Nutzerbereitstellung (SCIM) könnt ihr keine nicht abrechenbare Richtlinie nutzen.

2. Lokales Verzeichnis – Enthält Mitglieder, die ihr nicht in eurem Identity Provider verwaltet. Ihr ladet sie ein oder sie registrieren sich selbst.

3. Zwei-Schritt-Verifizierung – Beim Anmelden einen zweiten Schritt verlangen oder ihn für Mitglieder optional machen.

4. Passwortanforderungen – Mindeststärke und Ablauf von Passwörtern verwalten.

5. Dauer inaktiver Sitzungen – Festlegen, wie lange Mitglieder inaktiv sein dürfen, bevor sie abgemeldet werden.

6. Mitglieder – Zeigt die Anzahl der Mitglieder in einer Richtlinie an. Fügt Mitglieder hinzu oder verschiebt sie von einer Richtlinie in eine andere.

7. Single Sign-on (SSO) – Verwalten, wann die Anmeldung bei Atlassian über SAML oder Google Workspace SSO erzwungen wird. SSO kann nur in einem Verzeichnis eines Identity Providers erzwungen werden.

8. Verzeichnis des Identity Providers – Enthält Mitglieder, die ihr über euren Identity Provider synchronisiert oder authentifiziert. Ihr könnt Mitglieder zwischen Authentifizierungsrichtlinien hinzufügen und verschieben.

9. Ihr könnt eine nicht abrechenbare Richtlinie nur im lokalen Verzeichnis als Standardrichtlinie festlegen.

10. Bei Verwendung der Benutzerbereitstellung (SCIM) könnt ihr keine nicht abrechenbare Richtlinie verwenden.

Hinweis: Kunden können mehrere Authentifizierungsrichtlinien einrichten, maximal 20 pro Organisation.

Product Discovery – Wenn Kunden eine Domain verifizieren, sehen sie, wie viele verwaltete Accounts sich in ihrer Organisation befinden. Häufig entdecken Kunden unerwartete Benutzer von einer anderen Site, aus einem anderen Unternehmensbereich oder Mitarbeiter, die einfach kostenlose Trello-Accounts eingerichtet haben und nutzen. Verwendet der Atlassian-Account eines Benutzers die verifizierte Domain, wird er zu einem verwalteten Account.

Nicht abrechenbare Richtlinie – Kunden können eine nicht abrechenbare Richtlinie anwenden, wenn sie Benutzer von ihrem Access-Abonnement ausschließen möchten. Es gibt jedoch Einschränkungen, da einige Access-Funktionen keine nicht abrechenbaren Richtlinien zulassen und nur EINE nicht abrechenbare Richtlinie erlaubt ist.

Außerdem können Kunden Folgendes nicht:

• Single Sign-on für Benutzer in der nicht abrechenbaren Richtlinie erzwingen.

• Zwei-Schritt-Verifizierung für Benutzer in der nicht abrechenbaren Richtlinie verlangen.

• Benutzer, die über ihren Identity Provider (Okta, Azure AD, G Suite) synchronisiert werden, zur Richtlinie hinzufügen.

Access-Funktionen und nicht abrechenbare Richtlinien

Diese Tabelle erläutert, wie wichtige Access-Funktionen im Zusammenhang mit nicht abrechenbaren Richtlinien funktionieren.

* Alle Atlassian-Benutzerkonten für die beanspruchte Domain (z. B. amazingaccess.com).

Häufige Kundenfragen

• Jemand anderes in unserem Unternehmen hat unsere Unternehmensdomain (z. B. acme.com) beansprucht. Können wir Access und Single Sign-on nutzen?

• NEIN, da eine Domain nur von einer Atlassian-Access-Organisation bzw. einem Atlassian-Access-Abonnement beansprucht werden kann. Der Kunde müsste sich mit seinen Kollegen abstimmen, um eine gemeinsame Atlassian-Access-Organisation bzw. ein gemeinsames Atlassian-Access-Abonnement für sein Unternehmen einzurichten.

• NEIN, da eine Domain nur von einer Atlassian-Access-Organisation bzw. einem Atlassian-Access-Abonnement beansprucht werden kann.

• Der Kunde müsste sich mit seinen Kollegen abstimmen, um eine gemeinsame Atlassian-Access-Organisation bzw. ein gemeinsames Atlassian-Access-Abonnement für sein Unternehmen einzurichten.

• Können mehrere Jira- oder Confluence-Instanzen über unser Atlassian-Access-Abonnement verwaltet werden?

• JA. Eine Atlassian-Access-Organisation kann mehrere Atlassian-Produkte unterstützen, auch mehrere Sites desselben Produkts wie Jira oder Confluence.

• Wir haben viele kostenlose Trello-Konten. Können wir sie von Atlassian Access ausschließen?

• JA. Ihr könnt EINE „nicht abrechenbare“ Sicherheitsrichtlinie definieren, die alle darin enthaltenen Konten von der Atlassian-Access-Subscription, den Richtlinien und dem SAML Single Sign-on ausschließt.

• JA. Ihr könnt EINE „nicht abrechenbare“ Sicherheitsrichtlinie definieren, die alle darin enthaltenen Konten von der Atlassian-Access-Subscription, den Richtlinien und dem SAML Single Sign-on ausschließt.

• Wir verwenden GSuite und Google Accounts für die Anmeldung. Brauchen wir trotzdem Atlassian Access?

• NEIN. Ihr könnt GSuite und die Google-Anmeldung kostenlos nutzen. GSuite-Konten und -Domains werden kostenlos synchronisiert und benötigen kein Atlassian Access. Kunden können Access für mehr Sicherheit und bessere Koordination erwerben.

• NEIN. Ihr könnt GSuite und die Google-Anmeldung kostenlos nutzen.

• GSuite-Konten und -Domains werden kostenlos synchronisiert und benötigen kein Atlassian Access.

• Kunden können Access für mehr Sicherheit und bessere Koordination erwerben.