ニフティにおけるAtlassian製品のユーザー管理手法

ニフティにおける Atlassian製品のユーザー管理手法 JIRA/Confluence/BitbucketServer/Crowd 石川 貴之 / ニフティ株式会社 2017-10-10 Atlassian User Group #24 1

自己紹介 名前 石川 貴之 Ishikawa Takayuki 所属 ニフティ株式会社 WEBサービス開発グループ やっていること SNSとか R&Dからの自社サービス改善（最近は機械学習で画像解析） Atlassian製品のひとり管理者 • https://14code.com/blog/ • https://github.com/14kw • @14tter 2

• https://14code.com/blog/
• https://github.com/14kw

今日お話しすること • Atlassian Crowdとは • Crowd採用の経緯とAtlassian製品のユーザー管理 • 特別権限の付与 • ライセンス付与およびグループ管理 • 運用工数削減 • 失敗談 3

サーバー構成 4 Server版 License JIRA 500 Confluence 500 BitbucketServer 500 Crowd Unlimited

Atlassian Crowdとは 5

https://ja.atlassian.com/software/crowd 6

• https://ja.atlassian.com/software/crowd

https://ja.atlassian.com/software/crowd 7

• https://ja.atlassian.com/software/crowd

Crowd採用の経緯と Atlassian製品のユーザー管理 8

要件 9

要件 10

移行前の環境とAtlassian環境 Trac Atlassian 認証 @niftyユーザー認証 アカウント作成 各自@niftyユーザー名を取得 ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバーリス トにWebから追加 11 社員 外注先 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与

移行前の環境とAtlassian環境 Trac 認証 @niftyユーザー認証 アカウント作成 各自@niftyユーザー名を取得 ライセンス付与 Atlassian 社員 外注先 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与 @niftyサービス用アカウント なし を社内システムにも利用 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバーリス トにWebから追加 12

認証はなにで行うか • @niftyユーザー認証 • 社内のLDAP認証 • Atlassianユーザー管理で認証 13

@niftyユーザー認証のメリット・デメリット メリット • 【認証】 認証部分を持たなくていい • 【アカウント】パスワード忘れなどの対応をしなくて済む デメリット • 【認証】社内で普及している認証方法ではないため社員からログイン方法の問い合わせが来る • 【アカウント】アカウントの棚卸しが必要 • 【アカウント】社員であろうと@niftyユーザーIDの新規作成が必要 • 【アカウント】利用規約とパスワード入力の関係上、個々人で作ってもらう手間 14

LDAP認証のメリット・デメリット メリット • 【認証】認証部分を持たなくていい • 【認証】社内システムで使われている認証方法なので細かい説明が不要 • 【アカウント】LDAP管理ユーザーのアカウント棚卸しをしなくていい • 【アカウント】社員であれば自動で追加、削除される デメリット • 【認証】外注先のユーザーは別の認証方法が必要 • 運用上LDAPには外注先ユーザーの追加が難しい 15

利用者が慣れているログイン方法 棚卸しの簡易さが決め手となり LDAP認証を採用 ＋ 外注先の方はAtlassianの認証 16

どうLDAPと連携するか • 各アプリケーションからLDAPにつなげる • JIRAをベースとしてLDAPにつなげる • CrowdをベースとしてLDAPにつなげる • 外部IDaaSをベースとしてLDAPにつなげる 17

JIRAにユーザー管理を集約する • 利用する製品の合計利用者数分 JIRAのライセンスが必要になる • 併設しているSubversionの認証だけ別となり SSOにならない（Fisheyeは買ってない） • JIRAのユーザーディレクトリで外注先を管理すれ ば各アプリケーションで利用できる https://ja.confluence.atlassian.com/adminjiraserver075/connecting-to-crowd-or-another-jira-application-for-user-management-935391052.html 18

• https://ja.confluence.atlassian.com/adminjiraserver075/connecting-to-crowd-or-another-jira-application-for-user-management-935391052.html

Crowdにユーザー管理を集約する • Atlassian製品以外とも連携できる • Subversion（Apache）と連携できる https://ja.confluence.atlassian.com/crowd/integrating-crowd-with-subversion-104824970. html • 500の次はUmlimitedなので将来的にも安心 • Crowdのユーザーディレクトリで外注先を管理 すれば各アプリケーションで利用できる https://ja.confluence.atlassian.com/adminjiraserver075/connecting-to-crowd-or-another-jira-application-for-user-management-935391052.html 19

• https://ja.confluence.atlassian.com/crowd/integrating-crowd-with-subversion-104824970.html
• https://ja.confluence.atlassian.com/adminjiraserver075/connecting-to-crowd-or-another-jira-application-for-user-management-935391052.html

IDaaSにユーザー管理を集約する • 導入当時では外部のIDaaSの利用は難しかった • 利用サービスがAtlassian製品だけでは費用対効果が悪い 20

Atlassian製品との連携が簡単 ライセンスのUnlimitedが比較的安価 Crowdを採用 21

ユーザーディレクトリとグループの同期図 22

移行前の環境とAtlassian環境 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 ※あとで説明します ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバーリス トにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与 23

特別権限の付与 24

要件 25

移行前の環境とAtlassian環境 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 ※あとで説明します ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバーリス トにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与 26

一般権限と特別権限の仕様 社員 プロジェクトやスペースの 作成 外注先 自由 （JIRAは申請制、Subversionはリポジトリ追加禁止） プロジェクトやスペースの 閲覧 自由 権限のあるプロジェクト・スペースだけ プロジェクトやスペースの 編集 権限のあるプロジェクト・スペースだけ 権限のあるプロジェクト・スペースだけ 非公開プロジェクト・スペー スへの変更 プロジェクト管理者であれば 特権グループへの閲覧権限を削除することで可能 27

特別権限の仕様 • 外注先の方も利用するため xxx-users に対して全オープンにはできない • 当然 anonymous のアクセスは禁止 • Default Permissionとして特権グループに閲覧権限を付与する • 特権グループには社員のみ自動追加（cron処理） 28

JIRAのプロジェクト初期権限 特権グループ 29

Confluenceのスペース初期権限 特権グループ 30

Bitbucket Serverのプロジェクト初期権限 特権グループ Bitbucket ServerのGlobal Permissionは権限と同時に、 Bitbucket Serverのライセンス利用権限まで与えてしまうため cronで新規プロジェクトに対して初期権限を与えている 31

ユーザーディレクトリとグループの同期図 32

移行前の環境とAtlassian環境 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 ※あとで説明します ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 社員のID帯であれば自動付与 なし プロジェクト権限 社員がプロジェクトのメンバーリス トにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与 33

ライセンス付与およびグループ管理 34

要件 35

移行前の環境とAtlassian環境 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 申請 ライセンス付与 なし 申請 申請 特別権限 社員の業務用@niftyIDで認証 社員のID帯であれば自動付与 なし プロジェクト権限 社員がプロジェクトのメンバーリス トにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与 36

申請が多くなってしまう要因 • 社内ユーザー全員にライセンスを自動付与することはできない • 契約ライセンス500 • 社員数500＋外注先数xxx ちょっと溢れる • CrowdのAdmin権限がないとユーザー追加やグループ操作ができない • CrowdはAdministratorかRead Onlyしか権限管理できない • JIRA/Confluence/Bitbucket Serverどれもユーザー管理はAdmin権限が必要 37

運用工数削減 38

Crowdと連携した 社内向け管理画面を作成 39

通称：Crowd-Client • Crowdを介したLDAP認証でログイン • ユーザーの検索 • 非LDAPユーザーの追加 • 非LDAPユーザーのパスワードリセット • ユーザーの有効化・無効化 • 非LDAPユーザー情報の変更 • グループの検索 • グループへのメンバー追加・削除 • グループの追加 • 権限の確認（ライセンス付与者の確認） • 権限の追加（ライセンスの付与） 40

これで申請ともおさらば！ と思いきや 41

要件 42

社内調整 移行前から社外ユーザーの追加は自由だったが昔は昔、今は今。再調整。 • 追加対象とはNDA締結済であることが条件 • IPアドレス制限かけている • 証跡取ってます！ • 物理削除機能はないので元に戻せます！！ • 社員は悪いことしないと信じる！！！ と、いうようなことをセキュリティ担当にプレゼンします。 43

移行前の環境とAtlassian環境 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 社員がCrowd-Clientから付与 ライセンス付与 なし 社員がCrowd-Clientから付与 社員がCrowd-Clientから付与 特別権限 社員の業務用@niftyIDで認証 社員のID帯であれば自動付与 なし プロジェクト権限 社員がプロジェクトのメンバーリス トにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与 44

申請対応が7,8割削減 （移行の過渡期で多かったのもあり） 45

いつかなんとかしたいこと • JIRAのプロジェクト作成申請 • API使って作成させるようにしたいが初期スキームとかどうしよう • JIRAのプロジェクトごとのスキーム設定変更申請 • Project Level Administrationの範囲が拡大したのでアップグレードしたい • JIRAのWebhook追加申請 • あんまり増えるとJIRAが重くなるらしいので、それは困る • Webhook作成者の権限がJQLに適用されないためガバガバなJQLが来たら危険 46

失敗談 47

失敗談 • 導入初期、JIRAの管理権限を全社員に与えて プロジェクト作成・設定変更やユーザー管理の自由化を実現していた • JIRAの設定がカオスになった • CrowdやJIRAからライセンス上限を超えて権限付与できてしまう • ライセンス上限を超えてしまう事故 • ライセンス付与はCrowd-Clientからに集約（システム的に超えないようにしている） • LDAP Detegted Directoryのみで運用時、ログインと同時にユーザー作成＋ライセンス付与にしていた • ライセンス上限を超えてしまう事故 • 自動付与はやめてCrowd-Clientからの操作にする 48

失敗談 • LDAPがあるとき空になった • 空の状態を同期してユーザー全削除 • LDAP復旧後、再度同期したがプライマリキーが変わったようでグループの紐付けが全部消失 • LDAPから退職者の情報が物理的に消える • 連携ツール側の表示が「Unknown User (ログインID)」になり個人を推測しにくい • Delegated Authentication Directoryを別途作成し、 LDAP Directoryの差分（新規はuser add、削除はuser disable）を同期 各アプリケーションからはDelegated Authentication Directoryを利用するように変更 • プロジェクト権限に全ユーザーが入っているグループ（xxx-usersなど）を入れてしまう人がいる • 外注先の方もいるのだと意識を変えていく • バッチによる自動削除 49

まとめ 50

まとめ • Atlassian以外のツールもSSOでまとめたかったらCrowd使うと楽です • ライセンスを潤沢に買えるなら買いましょう、悩みも運用も減ります • 申請を減らして管理権限を一部の人に委ねましょう • 副次効果で社内のツール利用率も上がります（申請は心理的障壁がある） • 運用を楽にしたくてもJIRA Admin権限は与えてはダメ。ゼッタイ。 51

52