Ein Einsteiger-Datenblatt zu Atlassian Access

Atlassian Access ist ein unternehmensweites Abonnement, das eure Atlassian-Cloud-Produkte mit Ihrem Identitätsanbieter verbindet und es Ihnen ermöglicht, Authentifizierungsfunktionen auf Unternehmensniveau und zusätzliche Kontrolle über Ihre Unternehmensdomänen hinweg zu aktivieren. Für Erstanwender kann es jedoch schwierig sein, sich mit all den Begriffen und Bedeutungen vertraut zu machen, die damit verbunden sind.

Deshalb stellen wir Ihnen in diesem Blog ein Datenblatt zur Verfügung, das Sie für Access verwenden können. Im Folgenden finden Sie alle Begriffe und Definitionen, die ihr bei der Arbeit mit Access kennen solltet.

Was ist Atlassian Access?

Es handelt sich um ein Abonnement für eine Reihe von gekoppelten Einstellungen, die in einem "Atlassian Access"-Abonnement zusammengefasst sind. Es handelt sich nicht um eine Anwendung im Sinne von Jira und Confluence. Es ist wichtig, diese Unterscheidung von Anfang an zu verstehen, um zu begreifen, wie Access verwendet wird.

Was leistet Access?

Es ermöglicht Atlassian-Kunden die Anwendung von Sicherheitseinstellungen, SSO (Single Sign-On) und die Durchsetzung von Benutzerrichtlinien für ihre Atlassian Cloud-Produkte.

Mit welchen Atlassian-Produkten arbeitet Access zusammen?

• Jira-Software
• Jira Service-Verwaltung
• Jira Arbeitsverwaltung
• Confluence
• Bitbucket
• Trello
• Statusseite

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

Was sind seine Funktionen?

• SAML-Einzelanmeldung (erfordert einen SAML 2.0-Identitätsanbieter wie Azure AD, Okta, Google Workspace oder Identity One)
• Benutzerbereitstellung (SCIM) (erfordert Azure AD, Okta oder Google Workspace)
• Audit-Protokoll der Organisation
• API-Token-Kontrollen
• Erzwungene zweistufige Verifizierung
• Verwaltung der Sitzungsdauer
• Produkt-Erkennung

Wann wird Access empfohlen?

• Wenn zentral verwaltete Atlassian-Benutzerkonten erforderlich sind. Ohne Access ist jeder Benutzer für die Verwaltung seines individuellen Kontos verantwortlich.
• Wenn ihr Single Sign-On und automatisiertes SCIM-Benutzer-Provisioning anbieten möchtet. Dies ist in der Regel bei mehr als 250 Benutzern von großem Vorteil.
• Wenn Nutzer ihre Cloud-Anwendungen mit einem anderen externen Identitätsanbieter als Google Workspace verbinden möchten.
• Wenn ihr Nutzerrichtlinien für eure Atlassian-Cloud-Apps durchsetzen müsst, z. B. Passwortanforderungen, Zwei-Schritt-Verifizierung usw. Kunden haben oft Sicherheitsrichtlinien, die die Einhaltung einer Mindestpasswortlänge vorschreiben.

Wie wird der Zugang eingerichtet?

Atlassian-Konten oder -IDs - Um ein Atlassian-Cloud-Produkt zu nutzen, hat jeder Benutzer eine Atlassian-ID oder ein Konto, das eindeutig ist und in der Regel mit einer Unternehmensdomäne verbunden ist. Zum Beispiel:"amccallum@amazingaccess.com".

Domain-Verifizierung - Durch die Verwendung von Access teilt der Kunde Atlassian mit, dass diese Konten direkt vom Kunden verwaltet werden. Zu diesem Zweck müssen die Kunden die entsprechenden Domains über diesen Prozess beanspruchen und verifizieren .

Hinweis: Dies erfordert eine Abstimmung mit der IT-Abteilung des Kunden.

Verwaltete Konten - Sobald die Überprüfung der Domäne abgeschlossen ist, übernehmen alle Benutzerkonten diese beanspruchte(n) Domäne(n). In diesem Fall kann "@amazingaccess.com" vom Kunden verwaltet werden und fällt unter "Verwaltete Konten".

Hinweis: Der Administrator der Organisation kann auch alle verwalteten Benutzer deaktivieren und ihnen den Zugang zu allen Cloud-Produkten und allen Systemen, die Atlassian-Konten verwenden, entziehen.

Lizenzierung - Die Lizenzierungsmetrik für Access ist die Anzahl der "abrechenbaren Konten".

Abrechenbares Konto - Jedes verwaltete Konto, das Zugriff auf Jira Software, Jira Work Management, Confluence, Bitbucket, Jira Service Management (nur Agenten) oder Trello hat. Wenn ein Benutzer Zugriff auf eines dieser Produkte hat, gilt er als kostenpflichtig, d.h. ihr müsst eine Access-Benutzerlizenz für ihn bezahlen. Wenn ein Benutzer über mehrere Atlassian-Produkte verfügt (Jira Software, Confluence, Bitbucket usw.), müsst ihr nur eine Access-Lizenz für ihn bezahlen.

Preise - Wie andere Cloud-Produkte kann Access auf monatlicher Basis pro Benutzer oder auf Basis von Benutzerstufen erworben werden. Seht diesen Preiskalkulator. Eine Ausnahme bildet die Atlassian Enterprise Cloud, die Access als Teil des Enterprise-Abonnementpakets enthält.

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

Hinweis: Mit Organisation meinen wir eine "Atlassian Organisation", die eine virtuelle Hülle mit Atlassian-Produkten ist.

Innerhalb einer Atlassian Organisation kann ein Kunde eine oder mehrere Cloud-Sites haben. Jede Site kann eine Reihe von Atlassian-Produkten enthalten. Größere Atlassian-Unternehmenskunden können mehrere Atlassian-Organisationen in ihrem Unternehmen haben.

Wofür Kunden zahlen müssen - Wie bereits erwähnt, besteht Access im Wesentlichen aus gekoppelten Diensten. Die Lizenz und die Kosten hängen davon ab, was ihr tun möchtet und welche Atlassian-Produkte die Mitarbeiter im Unternehmen des Kunden verwenden. Kunden müssen nur für Benutzer zahlen, wenn sie Sicherheitseinstellungen über Authentifizierungsrichtlinien anwenden.

Verwaltete Konten - Ein Kunde kann eine Domäne verifizieren, verwaltete Konten erstellen und Konten verwalteter Benutzer kostenlos anzeigen/aktualisieren. Die verwalteten Konten werden zu kostenpflichtigen Benutzern, wenn der Kunde beginnt, Sicherheitseinstellungen anzuwenden, bei denen es sich um Access-Funktionen wie Authentifizierungsrichtlinien handelt.

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

Die folgenden Änderungen werden vorgenommen:

• Verwaltete Benutzer melden sich nicht mehr über SAML Single Sign-On an. Stattdessen melden sie sich mit ihrem Atlassian-Konto an. Einige Benutzer müssen möglicherweise ein neues Passwort für ihr Atlassian-Konto festlegen.
• Die zweistufige Verifizierung wird nicht mehr erzwungen, daher können verwaltete Benutzer diese für ihr Atlassian-Konto deaktivieren.

Die Organisation und die verifizierten Domains sind von der Abmeldung nicht betroffen. Die Fähigkeit des Organisationsadministrators, die Atlassian-Konten seiner verwalteten Benutzer einzusehen und zu aktualisieren, bleibt davon unberührt.

Authentifizierungsrichtlinien - In Access können Kunden mit Hilfe von Authentifizierungsrichtlinien Authentifizierungseinstellungen für verschiedene Benutzer festlegen. Möglicherweise verfügen sie über Benutzergruppen mit unterschiedlichen Sicherheitsanforderungen wie Mitarbeiter, Partner und Auftragnehmer usw.

Verfügbare Authentifizierungsrichtlinien in Access:

1. Nicht fakturierbar - Erstellt euch eine nicht fakturierbare Richtlinie, wenn ihr für bestimmte Benutzer nicht bezahlen möchtet.
   1. Ihr könnt eine nicht abrechenbare Richtlinie nur als Standardrichtlinie im lokalen Verzeichnis festlegen.
   2. Ihr könnt keine nicht abrechenbare Richtlinie erstellen, wenn ihr die Benutzerbereitstellung (SCIM) verwendet.
2. Lokales Verzeichnis - Enthält Mitglieder, die ihr nicht in eurem Identity Provider verwaltet. Ihr ladet sie ein, oder sie melden sich selbst an.
3. Zweistufige Überprüfung - Verlangt einen zweiten Schritt bei der Anmeldung oder macht ihn für Mitglieder optional.
4. Passwortanforderungen - Verfolgt die Mindeststärke und den Ablauf von Passwörtern.
5. Dauer der Leerlaufsitzung - Verfolgt, wie lange Mitglieder inaktiv sein können, bevor sie ausgeloggt werden.
6. Mitglieder - Zeigt die Anzahl der Mitglieder in einer Richtlinie an. Hinzufügen oder Verschieben von Mitgliedern aus einer Richtlinie in eine andere.
7. Single Sign-On (SSO) - Verfolgt, wann ihr die Anmeldung bei Atlassian über SAML oder Google Workspace SSO erzwingt. Ihr könnt SSO nur in einem Identitätsanbieterverzeichnis erzwingen.
8. Identitätsanbieterverzeichnis - Enthält Mitglieder, die ihr über euren Identitätsanbieter synchronisiert oder authentifiziert. Ihr könnt Mitglieder hinzufügen und zwischen Authentifizierungsrichtlinien verschieben.

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

Produktentdeckung - Wenn Kunden eine Domäne verifizieren, können sie sehen, wie viele verwaltete Konten in ihrer Organisation vorhanden sind. Es kommt häufig vor, dass Kunden unerwartete Benutzer von einem anderen Standort, einem anderen Teil des Unternehmens oder Mitarbeiter entdecken, die einfach kostenlose Trello-Konten einrichten und verwenden. Wenn das Atlassian-Konto eines Benutzers die von ihm verifizierte Domain verwendet, wird es zu einem verwalteten Konto.

Richtlinie für nicht abrechenbare Leistungen - Kunden können eine Richtlinie für nicht abrechenbare Leistungen anwenden, wenn ein Kunde Benutzer von seinem Access-Abonnement ausschließen möchte. Es gibt jedoch einige Einschränkungen, da einige Access-Funktionen keine nicht abrechenbaren Richtlinien zulassen, wobei nur EINE nicht abrechenbare Richtlinie erlaubt ist.

Außerdem können die Kunden nicht;

• Single Sign-On für Benutzer in der nicht abrechenbaren Richtlinie erzwingen.
• Eine zweistufige Verifizierung für Benutzer in der nicht abrechenbaren Richtlinie vorschreiben.
• Benutzer, die Sie von Ihrem Identitätsanbieter (Okta, Azure AD, G Suite) synchronisieren, der Richtlinie hinzufügen.

Zugriffsfunktionen und nicht abrechenbare Richtlinien

In dieser Tabelle wird erläutert, wie die wichtigsten Zugriffsfunktionen in Bezug auf nicht abrechenbare Richtlinien funktionieren.

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

Häufige Kundenfragen

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

• • NEIN, da eine Domain nur von einer Atlassian Access-Organisation/einem Atlassian Access-Abonnement beansprucht werden kann.
  • Der Kunde muss sich mit seinen Kollegen abstimmen, um eine einzige Atlassian Access-Organisation/ein einziges Atlassian Access-Abonnement für sein Unternehmen zu erhalten.

• Können wir mehrere Jira- oder Confluence-Instanzen über unser Atlassian Access-Abonnement verwalten lassen?

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

• Wir haben viele kostenlose Trello-Konten. Kann ich diese von Atlassian Access ausschließen?

• • JA. Ihr könnt EINE "nicht abrechenbare" Sicherheitsrichtlinie definieren, die alle enthaltenen Konten vom Atlassian Access-Abonnement, den Richtlinien und SAML Single Sign-On ausschließt.

• Wir verwenden GSuite und Google-Konten für die Anmeldung, benötige ich trotzdem Atlassian Access?

• • NEIN. Ihr könnt GSuite und Google Login kostenlos nutzen.
  • GSuite-Konten und -Domänen werden kostenlos synchronisiert und benötigen keinen Atlassian Access.
  • Für mehr Sicherheit und Koordination können Kunden Access kaufen.