情シスの引継ぎが大変という話

情シスの引継ぎが大変という話 ~なぜこんなにも引継ぎがうまくいかないのか？~

Transcript

1. 情シスの引継ぎが大変という話 なぜこんなにもうまくいかないのか？ Miyu Sakatsuki
2. 目次 1. なぜ情シスの引継ぎは難しいのか 2. 引継ぎの失敗事例（引き継がれた側目線） 3. 効果的な引継ぎのためのアプローチ 4. おわりに
3. 注意 これは、すべての「情シス引継ぎ」に対応するものではございません。
4. 1. なぜ情シスの引継ぎは難しいのか 情報システム部の人事異動・人員変更発生時に必要なことは、 知識の引継ぎではなくシステムの引継ぎである 十分なスキル を持ち合わせていたとしても、組織特有のシステ ムへの理解がないと失敗に終わる ※当然スキルも重要、スキルがある前提のお話 ※
5. 情シスにおける引継ぎの特殊性 情シスにおける引継ぎには以下のような特性が存在する 1. なぜ情シスの引継ぎは難しいのか 他の職種とは違い、1つのミスで組織活動を一発で 停止させるレベルのダメージを与えることができてしまう 恐らく一番影響度が高い
6. 特殊性：技術の進化(変化) 引き継ぎ期間中も、利用している技術やシステムはアップデート や仕様変更が発生する • 今日動いていたものが明日には動かなくなる • 昨日まで非常識だったものが今日には常識になっているかも 1. なぜ情シスの引継ぎは難しいのか 技術進化 複雑化
7. 特殊性：システムの相互依存 • 1つのシステムやアカウントが広域に影響を及ぼす可能性 • これらは時限的に起こりうる(発見が遅れる)大変怖いもの • 予期せぬサービスの停止（最悪の場合サービス自動解約） 1. なぜ情シスの引継ぎは難しいのか 情シスアカウント停止 請求管理者の不在 連携サービス不具合 管理者不在状態または ログイン不可能に 重要な通知の見逃し 困った… 即時発生することもあれば、 時間経過してから起こることもある
8. 特殊性：システムの相互依存 -2 • 実際に対象者のアカウントが削除されないと影響確認できない • 事前の削除が許されていたとしても影響自体は回避できない → ん？影響確認という行為自体が危険なのでは？ → 影響はわからないが、影響が出ないように対策する？ → ちょっと何言ってるのかわからない… 1. なぜ情シスの引継ぎは難しいのか
9. 特殊性：社内プロジェクト・案件の継続性 • 情シスは他部署依頼のサービスの導入や構築などの第一人者に なりがち（これが良い悪いの話ではない） • 情シスは少人数である場合が多い（と思われる）のに、責任が 集中し、疲弊する • 属人化しており、1人しかシステム面を把握していない • 引継ぎという現実から逃避したくなる (引き継がれる側・引き継ぐ側どちらも) 1. なぜ情シスの引継ぎは難しいのか
10. 特殊性：セキュリティ・ガバナンス • セキュリティ周りの兼任は情シスあるある（専門部隊がいない場合） • 規定等によりセキュリティ対応が標準化がされていない場 合、”主観(個人的見解)”または過去の実績を鑑みた対応が組織 の決定となる • 例：以前はこうだったので今回もこうすればいい • 例：よくわからんが取り急ぎの権限はこれにしよう 言語化されていない情報を引き継ぎできる訳がない 場合によっては残念ながら責任はあなたに 1. なぜ情シスの引継ぎは難しいのか
11. 特殊性（番外編）：はびこる暗黙知 • 手順には存在しないが実は実施しないといけないもの • 例：XYZ部の人は少し特殊なのでABCメーリングリストに入れないといけない • 暗黙「知」だが、システム側の制約等で行われることが殆どで、本来この手順を把握するので はなくシステムの仕様（設定）を把握しておかなければならないことに注意 • 暫定対応されたものが定常化してしまっていることが多い • 担当者はこれが当たり前だと思っているので情報が引き継がれない 当たり前ではないことが 当たり前のように扱われている業務はありませんか…? 1. なぜ情シスの引継ぎは難しいのか
12. 2. 引継ぎの失敗事例 実際に経験した失敗事例とその他妄想を紹介 主にこちらの事例
13. 事例1：Google Cloud プロジェクト閉鎖 • 退職する情シス担当者のGoogle Workspace アカウントを削除したところ、 複数のGoogle Cloud プロジェクトが閉鎖される大事件 • 謎の汗が放出されると共に、この世の終わりの合図が聞こえた • 「Google Cloudにアクセスできなくなりました」で正気が保てなかった 2. 引継ぎの失敗事例
14. 事例1：Google Cloud プロジェクト閉鎖 • 原因 • Google Cloud 請求先アカウントの支払いプロファイルが 削除されたアカウントに紐づくクレジットカードだった • 事前の調査でも気が付けなかった… • 影響 • 課金できなくなったことで実質的にプロジェクトが閉鎖 • 多くのサービスが一時的に停止した • 対応 • 請求先アカウントおよび支払いプロファイルの見直し ちなみに、削除したGWSアカウントを復旧してもこの事象は解決しなかっ たので本当に終わりだと思った 2. 引継ぎの失敗事例
15. 事例2：多要素認証を突破できない • MDM環境で、プッシュ証明書更新のためにApple Push Certificate Portal にログインを試みたところ、退職した情シスの電話番号を利用した多要素 認証があり、ログインできなくなった 2. 引継ぎの失敗事例
16. 事例2：多要素認証を突破できない • 原因 • 単純に対象の電話番号にアクセスできないためログインできなくなった • ログイン時の多要素認証の存在が考慮できていなかった • 利用頻度が低いサービスのため、事前確認ができていなかった • 影響 • プッシュ証明書の更新作業が一時的にできなかった • 対応 • 幸いクラウド電話環境で該当電話番号をプールしていたので、その番号を再利用し てログイン、アカウント情報から番号を変更した。 2. 引継ぎの失敗事例
17. 事例3：様々なPATが各所で使われている • サービスごとに発行できるパーソナルアクセストークンが無効に • 様々なサービス連携がことごとく止まる • 利用頻度は低いものの止まると困る系サービスがあぶり出された 2. 引継ぎの失敗事例 Error : 401
18. 事例3：様々なPATが各所で使われている 2. 引継ぎの失敗事例 • 原因 • 軽い気持ちでPATをクリティカルな業務システムに組み込みがち • PAT発行の事実は分かっていたが利用先が分からないものがあった • 影響 • サービス連携停止 • 業務自動化の仕組みが動かない • 対応 • 別のユーザでPATを発行し、トークンを置き換えた 週1で動くジョブなどになると、発見が遅れる PAT以外にもOAuth認証されている場合も同様にOUT
19. 事例4：プライマリオーナー不在 • サービスによっては権限の強い管理者：プライマリオーナーが存在する • サービス導入された方が自動的になるパターンが多い • プライマリオーナーが不在になることで、特定のアクションができなくなった • 例：請求管理・ユーザ等データの削除・新たな管理者の追加・破壊的操作 2. 引継ぎの失敗事例
20. 事例4：プライマリオーナー不在 2. 引継ぎの失敗事例 • 原因 • 対象システムの管理者ロールを理解していなかった • 影響 • 特定の作業が実施できなくなる • 契約更新できなくなることでサービス停止（の可能性） • 対応 • なんとか元のユーザでログインし権限移譲した
21. 3. 効果的な引継ぎのためのアプローチ どうすれば影響範囲を限りなく小さくできるのだろうか…? システム アカウント 契約管理 管理者の移譲 請求先設定 SaaS・サーバ 連携 業務 ドキュメント 過去の経緯 仕様変更 管理者の削除 入社退職対応 権限管理
22. アカウント削除時の影響を考慮する • とにかくアカウントを削除した時の影響を第一に考えなければならない • セキュアな環境を構築している組織ほど、削除したアカウントへのアクセスが困難(IdP経由などが理由) • 考慮しなければいけない事項が多いのに加えて、早めに洗い出して事前に対応する必要がある • 考慮事項 1. プライマリオーナーではないか？ 2. アクセストークンを個別で発行してどこかで利用していないか？ 3. 請求管理者ではないか？ 4. 携帯電話番号の認証を使ってログインしているサービスはないか？ 5. 個人に紐づいているような認証情報はないか？ 6. 重要な通知先は個人宛ではないか？ 3.効果的な引継ぎのためのアプローチ
23. システム運用の暗黙知を排除する • その組織のシステム特有の事象や対応方法を可能な限り言語化する • 「俺は雰囲気でこれらのシステムを管理している」 • 「俺たちは雰囲気でこれらのシステムをチームで管理している」状態にしておくことが理想 • 引継ぎすることが多すぎてそんな事してられない…? • 引継ぎには当然ながらタイムリミットがある • 普段から「雰囲気で作業」していることを排除していく必要がある • 逆にそれ以外は一般的なドキュメント読み込み・スキルでカバー可能なことが多い 3.効果的な引継ぎのためのアプローチ
24. 完璧な引継ぎを目指さない • 100%完璧な引継ぎはどうあがいても不可能 • 想定される最悪のトラブルを考えてみる • 組織のコアとなるシステムトラブルだけは避けられるようにする • 小さな部分はインシデントドリブンでも構わないと割り切る • 引継ぐ側・引継がれる側どちらもツラい！（全職種共通） • 限られた期間・限られたリソースでの対応はツラい • そもそも引継ぐ側が既に失踪していたり、逆に引き継がれる側が存在しないこともある • みんな同じ、みんなツラい。情シスコミュニティをうまく活用してみるのもアリ。 3.効果的な引継ぎのためのアプローチ
25. 4. おわりに • 情シスの引継ぎは、様々なモノ・コトに絡み合っており、紐解いていく必要があるため 決して簡単ではない。ミスると大事故に繋がる • 特定サービスの知識ではなく、組織特有のシステム運用の引継ぎが重要である • 引継ぎのための引継ぎ作業をしないため、イレギュラー的な対応を無くし標準化する • 管理者変更時、どのような事を考慮しないといけないかを知っておく
26. Thank you!