くらめその情シス“技”:ユーザー管理(Active Directory) from Developers.IO
クラスメソッドでIT推進室室長を務める植木氏。社内ツールやサービスの導入、見直しをする情シスの親分ともいえる存在。そんな植木氏のクラスメソッドでの取り組みを紹介する「くらめその情シス”技”」。一人情シスやゼロ情シスで頭を抱えている情シスさんのヒントにしてはいかがでしょうか?
くらめその情シス“技”:ユーザー管理(Active Directory)
クラスメソッドにてIT推進室を任せられている植木です。ここではこれまでに行った取り組みなども振り返りつつ、現在の課題と今後の施策をまとめました。同じ情シスの皆様のご参考になればと思います。
第1回は「ユーザー管理」についてです。
私がクラスメソッドに入社したのは2013年5月でした。当時は社員40人ほど、拠点も秋葉原本社の1つのみでした。その後5年(執筆時点)が経過し、社員は200名強、拠点は札幌・東京・大阪・福岡・上越・那覇などの国内拠点に加え、海外拠点もベルリン、バンクーバーと拡大して参りました。
少人数では十分だった仕組みや体制ですが、社員や拠点が増加することで、運用に耐えられなくなる点がでてきます。その為に行った施策をご紹介します。
この記事の目次
ユーザー管理システム
Active Directory
ユーザー管理にはActive Directory(AD)を利用しています。クラスメソッドは元々JavaやFlexの受託開発がメインだったということで、Windows機がほとんどでした。また拠点も本社1箇所のみで、リモートワークもそれほど積極的には行われてこなかったようです(VPNは存在していました)。
そのため社内のサーバー室に物理サーバー2台を用意し、それぞれADのプライマリとバックアップとして稼働させていました。内1台はファイルサーバーも兼ねていました。
G Suite (Google Apps)
メールはGmailを利用しています。GmailのユーザーはActive Directoryとは特に連携しておらず、入社時にADのユーザーと共にユーザーを作成してきました。
ちなみにG Suiteへのログインにはサテライトオフィスという(IdP:認証プロバイダー)サービスを利用しており、実際のユーザー認証はこちらで管理しています。
つまりG Suiteに加え、サテライトオフィスにもユーザーを作成してあげる必要があります。(G Suite自体のユーザーとパスワードは一般社員には公開していません)
5年間のできごと
2018年現在、一般的な会社では珍しいかも知れませんが、社内パソコン(PC)の7割がmacOSになりました。
また、社内チャットやWikiなど業務で利用するクラウドサービス(SaaS)がたくさん増えました。その為、サービス毎にユーザーを追加、削除するID管理業務負荷が高くなってきました。特にここ数年は毎月毎月メンバーが増えているため、どうにかこの負担を減らすことが求められました。
また、セキュリティの観点からも検討が必要になりました。利用するサービスが増えた為、仮にPCの紛失・盗難や、社員の退職等があったときにも即時に各サービスの権限を剥奪(または一時停止)するのが困難な状況でした。
その為、2014年にADサーバー2台を自社サーバー室からAmazon EC2に引っ越しました。
実施した施策と今
Active Directoryとサテライトオフィスをメインとしたユーザー管理の仕組みは、今も昔も変わってはいません。
2015年だったと思いますが、サテライトオフィスが提供するサービスがリニューアルされたこともあり、これと合わせてADとサテライトオフィスのユーザーを同期する仕組みを導入しました。これによりADにユーザーを追加すれば自動的にサテライトオフィスにもユーザーが作成されるようになりました。またADのユーザーをロックすればサテライトオフィスのユーザーも一時停止できるようになりました。
ユーザーを一元管理できるようになったことから、サテライトオフィスを利用したシングルサインオン(SSO)も導入しました。各種サービスがSAMLによるSSOに対応していれば、ユーザーは個別のログインは不要で、サテライトオフィスにログインするだけでサービス(例えばSalesforceやSansanなど)を利用することができます。現在も対応サービスを順次展開中です。
AWSのWorkspaces等を利用するため、社内ADとAWS Directory Serviceの間はAD Connectorを利用して連携しています。
またMicrosoft オフィスのライセンスはOffice365に移行したため、社内ADとAzure ADの間もAD Connectorを利用して同期しています。
尚、社内チャット(Chatwork)については、もしパスワード忘れなどによりADにログインできなくなった場合にメール等々が一切使えず連絡手段がなくなるという事情から、SSOの対象外としています。
課題と今後について
これまでの対策により、ユーザーを一元管理できるようになり、ユーザーの追加・削除の手間が減りました。また、社員からもSSOでログインが楽になったと好評でした。
しかしながら、課題も残っています。
課題1:ユーザーの新規作成と削除
サテライトオフィスで行っているのは、あくまでログイン(サインオン)部分だけです。各サービスのユーザー登録は個別に行わなければなりません。
各サービスでは「ユーザーの自動プロビジョニング」という、“初回ログイン時にユーザーがいなければ作成する”という機能が提供されている場合もあります。但し、サービスによって対応・非対応がマチマチであり、その為現状は個別に作成する運用にしています。
課題2:権限(グループ)の管理
認証をSSOで行った後、そのユーザーがどんな権限を持つかはサービス毎に管理しています。
Wikiページ、gitリポジトリ、メーリングリスト等々、サービスによってグループ分けや与えたい権限(参照のみ、変更可)は変わってくるものです。
本当はADのグループで一元管理しつつ各サービスにグループを同期して権限管理ができればいいのですが、上記理由から行っていません。
権限の一元管理をするには厳密で明文化された組織や職務の管理が必要になります。本当はやった方がいいし、今後の会社の成長を考えるとやるべきなのでしょうが、なかなか難しいのが実情です。
課題3:端末認証
万が一ユーザーのパスワードが漏洩した場合にも、会社で認められたPCからでないとログインができないようになっていれば更に安全となります。
またWindowsやMacのログインが認証プロバイダーと同期できれば、PCにログインすれば各種サービスが利用できるようになります。
まとめ
社員や拠点の増加、macOS端末の増加、利用サービスの増加に伴い、ユーザー管理の方法について見直しをしてきました。
サービス毎にユーザーを管理するのではなく、「ログイン情報を一箇所にまとめ、そこのセキュリティを強化することで、情報漏洩を防ぐ」という方針で行っています。
しかしながら、管理という点ではまだ道半ばです。
- OneLoginやAzure ADなど、より高度で監査機能も許可された認証基盤の利用
- 指紋など生体認証の利用検討
- OSパッチやアンチウイルスソフトが最新状態になっていなければシステムの利用を許可しないなど取り組み
- 不審なログイン(失敗)履歴の検出や通知
など取り組むべき課題はまだまだ残っています。
現在弊社では「Zero Trust Network」をキーワードに社内認証基盤の見直しを行っています。つまり「認められた人が」「認められた端末から」「ただしい職務に基づいて」システムを利用にする仕組みです。まだ世の中にもお手本となる実装例がなく手探り状態ですが、リモートワークを始めとした多様な働き方を情報システムとして支援するため取り組んでいます。
植木和樹(うえき・かずき)
クラスメソッド株式会社IT推進室室長。IT推進室は2017年7月に正式に開始された部門であり、情シス・経理・労務・営業・マーケといった部門にツールやサービスを展開し、業務を見直すことで効率的な事業・業務が行えることを支援している。
個人としては、WEB黎明期よりホームページ制作やシステム開発に従事する。長らく新潟で製造向けの社内システムの保守運用を行ってきたが、2008年の不況のあおりを受け退職。どうにか地元でITの仕事ができないかという思いでクラウドに興味を持ち、ツイッターで募集していたAWSエンジニアの採用に応募して、現在に至る。
業務の傍ら、月間200万PVを超えるBlog「Developers.IO」にも執筆を行う。