ニフティにおけるAtlassian製品のユーザー管理手法
•Descargar como PPTX, PDF•
1 recomendación•4,246 vistas
JIRA/Confluence/BitbucketServer/Subversionのユーザー管理を集約しSSOも実現するためにCrowdを採用した話と申請業務を減らし運用改善を行った話
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a ニフティにおけるAtlassian製品のユーザー管理手法
Similar a ニフティにおけるAtlassian製品のユーザー管理手法 (20)
Último
Último (8)
ニフティにおけるAtlassian製品のユーザー管理手法
- 1. ニフティにおける Atlassian製品のユーザー管理手法 2017-10-10 Atlassian User Group #24 1 石川 貴之 / ニフティ株式会社 JIRA/Confluence/BitbucketServer/Crowd
- 2. 自己紹介 2 名前 石川 貴之 Ishikawa Takayuki 所属 ニフティ株式会社 WEBサービス開発グループ やっていること R&Dからの自社サービス改善（最近は機械学習で画像解析） Atlassian製品のひとり管理者 SNSとか • https://14code.com/blog/ • https://github.com/14kw • @14tter
- 3. 今日お話しすること • Atlassian Crowdとは • Crowd採用の経緯とAtlassian製品のユーザー管理 • 特別権限の付与 • ライセンス付与およびグループ管理 • 運用工数削減 • 失敗談 3
- 4. 4 Server版 License JIRA 500 Confluence 500 BitbucketServer 500 Crowd Unlimited サーバー構成
- 9. 要件 9
- 10. 要件 10
- 11. 移行前の環境とAtlassian環境 11 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 アカウント作成 各自@niftyユーザー名を取得 ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバ ーリストにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与
- 12. 移行前の環境とAtlassian環境 12 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 アカウント作成 各自@niftyユーザー名を取得 ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバ ーリストにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与 @niftyサービス用アカウン トを社内システムにも利用
- 13. 認証はなにで行うか • @niftyユーザー認証 • 社内のLDAP認証 • Atlassianユーザー管理で認証 13
- 14. メリット • 【認証】 認証部分を持たなくていい • 【アカウント】パスワード忘れなどの対応をしなくて済む デメリット • 【認証】社内で普及している認証方法ではないため社員からログイン方法の問い合わせが来る • 【アカウント】アカウントの棚卸しが必要 • 【アカウント】社員であろうと@niftyユーザーIDの新規作成が必要 • 【アカウント】利用規約とパスワード入力の関係上、個々人で作ってもらう手間 14 @niftyユーザー認証のメリット・デメリット
- 17. どうLDAPと連携するか • 各アプリケーションからLDAPにつなげる • JIRAをベースとしてLDAPにつなげる • CrowdをベースとしてLDAPにつなげる • 外部IDaaSをベースとしてLDAPにつなげる 17
- 18. JIRAにユーザー管理を集約する • 利用する製品の合計利用者数分 JIRAのライセンスが必要になる • 併設しているSubversionの認証だけ別となり SSOにならない（Fisheyeは買ってない） • JIRAのユーザーディレクトリで外注先を管理 すれば各アプリケーションで利用できる 18 https://ja.confluence.atlassian.com/adminjiraserver075/connecting-to-crowd-or-another-jira-application-for-user-management-935391052.html
- 19. Crowdにユーザー管理を集約する • Atlassian製品以外とも連携できる • Subversion（Apache）と連携できる https://ja.confluence.atlassian.com/crowd/integrating-crowd-with-subversion- 104824970.html • 500の次はUmlimitedなので将来的にも安心 • Crowdのユーザーディレクトリで外注先を管 理すれば各アプリケーションで利用できる 19 https://ja.confluence.atlassian.com/adminjiraserver075/connecting-to-crowd-or-another-jira-application-for-user-management-935391052.html
- 23. 移行前の環境とAtlassian環境 23 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 ※あとで説明します ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバ ーリストにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与
- 24. 特別権限の付与 24
- 25. 要件 25
- 26. 移行前の環境とAtlassian環境 26 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 ※あとで説明します ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 プロジェクト権限 社員がプロジェクトのメンバ ーリストにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与
- 27. 27 一般権限と特別権限の仕様 社員 外注先 プロジェクトやスペース の作成 自由 （JIRAは申請制、Subversionはリポジトリ追加禁止） プロジェクトやスペース の閲覧 自由 権限のあるプロジェクト・スペースだけ プロジェクトやスペース の編集 権限のあるプロジェクト・スペースだけ 権限のあるプロジェクト・スペースだけ 非公開プロジェクト・ス ペースへの変更 プロジェクト管理者であれば 特権グループへの閲覧権限を削除することで可能
- 28. 特別権限の仕様 • 外注先の方も利用するため xxx-users に対して全オープンにはできない • 当然 anonymous のアクセスは禁止 • Default Permissionとして特権グループに閲覧権限を付与する • 特権グループには社員のみ自動追加（cron処理） 28
- 31. 31 Bitbucket ServerのGlobal Permissionは権限と同時に、 Bitbucket Serverのライセンス利用権限まで与えてしまうため cronで新規プロジェクトに対して初期権限を与えている Bitbucket Serverのプロジェクト初期権限 特権グループ
- 33. 移行前の環境とAtlassian環境 33 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 ※あとで説明します ライセンス付与 なし 特別権限 社員の業務用@niftyIDで認証 社員のID帯であれば自動付与 なし プロジェクト権限 社員がプロジェクトのメンバ ーリストにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与
- 35. 要件 35
- 36. 移行前の環境とAtlassian環境 36 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 申請 ライセンス付与 なし 申請 申請 特別権限 社員の業務用@niftyIDで認証 社員のID帯であれば自動付与 なし プロジェクト権限 社員がプロジェクトのメンバ ーリストにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与
- 37. 申請が多くなってしまう要因 • 社内ユーザー全員にライセンスを自動付与することはできない • 契約ライセンス500 • 社員数500＋外注先数xxx ちょっと溢れる • CrowdのAdmin権限がないとユーザー追加やグループ操作ができない • CrowdはAdministratorかRead Onlyしか権限管理できない • JIRA/Confluence/Bitbucket Serverどれもユーザー管理はAdmin権限が必要 37
- 38. 運用工数削減 38
- 40. 通称：Crowd-Client • Crowdを介したLDAP認証でログイン • ユーザーの検索 • 非LDAPユーザーの追加 • 非LDAPユーザーのパスワードリセット • ユーザーの有効化・無効化 • 非LDAPユーザー情報の変更 • グループの検索 • グループへのメンバー追加・削除 • グループの追加 • 権限の確認（ライセンス付与者の確認） • 権限の追加（ライセンスの付与） 40
- 42. 要件 42
- 43. 社内調整 移行前から社外ユーザーの追加は自由だったが昔は昔、今は今。再調整。 • 追加対象とはNDA締結済であることが条件 • IPアドレス制限かけている • 証跡取ってます！ • 物理削除機能はないので元に戻せます！！ • 社員は悪いことしないと信じる！！！ と、いうようなことをセキュリティ担当にプレゼンします。 43
- 44. 移行前の環境とAtlassian環境 44 Trac Atlassian 社員 外注先 認証 @niftyユーザー認証 社内のLDAP認証 Crowd認証 アカウント作成 各自@niftyユーザー名を取得 LDAPに自動追加 社員がCrowd-Clientから付与 ライセンス付与 なし 社員がCrowd-Clientから付与 社員がCrowd-Clientから付与 特別権限 社員の業務用@niftyIDで認証 社員のID帯であれば自動付与 なし プロジェクト権限 社員がプロジェクトのメンバ ーリストにWebから追加 プロジェクト管理者が 権限を付与 プロジェクト管理者が 権限を付与
- 46. いつかなんとかしたいこと • JIRAのプロジェクト作成申請 •API使って作成させるようにしたいが初期スキームとかどうしよう • JIRAのプロジェクトごとのスキーム設定変更申請 •Project Level Administrationの範囲が拡大したのでアップグレードしたい • JIRAのWebhook追加申請 •あんまり増えるとJIRAが重くなるらしいので、それは困る •Webhook作成者の権限がJQLに適用されないためガバガバなJQLが来たら危険 46
- 47. 失敗談 47
- 48. 失敗談 • 導入初期、JIRAの管理権限を全社員に与えて プロジェクト作成・設定変更やユーザー管理の自由化を実現していた •JIRAの設定がカオスになった • CrowdやJIRAからライセンス上限を超えて権限付与できてしまう •ライセンス上限を超えてしまう事故 •ライセンス付与はCrowd-Clientからに集約（システム的に超えないようにしている） • LDAP Detegted Directoryのみで運用時、ログインと同時にユーザー作成＋ライセンス付与にしていた •ライセンス上限を超えてしまう事故 •自動付与はやめてCrowd-Clientからの操作にする 48
- 49. 失敗談 • LDAPがあるとき空になった •空の状態を同期してユーザー全削除 •LDAP復旧後、再度同期したがプライマリキーが変わったようでグループの紐付けが全部消失 • LDAPから退職者の情報が物理的に消える •連携ツール側の表示が「Unknown User (ログインID)」になり個人を推測しにくい •Delegated Authentication Directoryを別途作成し、 LDAP Directoryの差分（新規はuser add、削除はuser disable）を同期 各アプリケーションからはDelegated Authentication Directoryを利用するように変更 • プロジェクト権限に全ユーザーが入っているグループ（xxx-usersなど）を入れてしまう人がいる •外注先の方もいるのだと意識を変えていく •バッチによる自動削除 49
- 50. まとめ 50
- 51. まとめ • Atlassian以外のツールもSSOでまとめたかったらCrowd使うと楽です • ライセンスを潤沢に買えるなら買いましょう、悩みも運用も減ります • 申請を減らして管理権限を一部の人に委ねましょう • 副次効果で社内のツール利用率も上がります（申請は心理的障壁がある） • 運用を楽にしたくてもJIRA Admin権限は与えてはダメ。ゼッタイ。 51
- 52. 52