こんにちは、インフラエンジニアのryuです。
新人インフラエンジニアが配属されたとき、本番環境のアカウントはどうしているでしょうか。
先輩と同じ管理者権限のアカウントを、とりあえず発行している。あるいは逆に、事故が怖いので半年たっても本番には一切ログインさせていない。
どちらも現場ではよく見かける光景です。そして、どちらにも困ったことが起きます。
前者では、新人が手順を一行読み飛ばしただけで、サービスが止まることがあります。後者では、新人がいつまでも本番の姿を知らないまま、障害の場に呼ばれて固まってしまいます。
今日は、新人インフラエンジニアに本番環境の権限をどう渡していくかを考えてみます。キーワードは、見る・触る・変えるの3段階です。
なぜ「全部渡す」も「何も渡さない」もうまくいかないのか？¶
最初に、よくある2つのやり方で何が起きるのかを整理しておきます。問題の形が分かると、どこに段階を置けばいいかが見えてきます。
最初から管理者権限を渡すと、事故の大きさが本人の注意力しだいになる¶
管理者権限を渡すのは、運転免許を取ったばかりの人に、大型トラックの鍵を渡すようなものです。
本人に悪気はまったくありません。でも、sudo で実行した一行が、どこまで影響するのかを新人はまだ知りません。本番とステージングのターミナルを取り違えることもあります。
このやり方では、事故の大きさが新人の注意力だけで決まってしまいます。仕組みで防ぐ部分がどこにもありません。
さらに、権限は一度広く渡すと、あとから削るのが難しくなります。「前はできたのに」という声が出るからです。
何も渡さないと、本番を知らないまま障害対応に呼ばれる¶
では、権限を一切渡さなければ安全なのでしょうか。
短期的には安全です。ただ、新人は本番のサーバーにどんなプロセスが動き、どんなログが出ているのかを見る機会がありません。
その状態で夜間の障害対応に入ると、ログの場所から先輩に聞くことになります。障害のさなかに、それを一から教える余裕はありません。
つまり、権限を渡さないことは、事故のリスクを消すのではなく、あとに先送りしているだけです。
権限の渡し方の土台になる「最小権限」の考え方¶
ここで、セキュリティの世界で昔から使われている考え方を借ります。最小権限の原則です。
米国のNIST（国立標準技術研究所）は、用語集でこの原則を次のように説明しています。
ユーザー（またはユーザーの代わりに動くプロセス）のアクセス権限を、割り当てられた業務を行うのに必要な最小限に制限すべきである、というセキュリティの原則。（NIST CSRC Glossary「least privilege」より要約）
日本でも、IPAの「組織における内部不正防止ガイドライン」が、アクセス権限を付与する人と権限の範囲を必要最小限にすることや、定期的に見直すことを求めています。
ここで大事なのは、最小権限は「少なく渡せ」という意味ではない点です。業務に必要な分は渡し、必要がなくなったら戻すという、動きのある考え方です。
新人の業務は、成長にあわせて月ごとに変わります。だから権限も、業務の変化にあわせて段階的に広げていくのが自然です。
見る・触る・変える、3段階で権限を設計してみよう¶
では、具体的な段階を考えてみます。私がおすすめしているのは、本番環境への関わり方を3つに分ける方法です。
次の表に、それぞれの段階で渡す権限と、新人ができるようになることをまとめました。
| 段階 | 渡す権限の例 | 新人ができること | 事故が起きたときの影響 |
|---|---|---|---|
| 1. 見る | 読み取り専用アカウント、監視ダッシュボード、ログ閲覧 | 状態の確認、ログ調査、障害時の情報集め | ほぼなし |
| 2. 触る | 決められたコマンドだけ sudo で実行できる権限 |
サービスの状態確認、定型の再起動 | 限定的（決めた操作の範囲） |
| 3. 変える | 設定変更やデプロイの権限（承認つき） | 手順書にもとづく変更作業 | 大きい（だから承認とレビューで守る） |
図書館にたとえると分かりやすいかもしれません。
最初は閲覧室で本を読むだけ。次に、貸出カウンターで決まった手続きだけを担当する。最後に、蔵書の配置を変える仕事を任される。いきなり書庫の鍵を渡す図書館はありません。
段階1「見る」は、配属直後から渡してよい¶
読み取り専用の権限は、できるだけ早く渡すのがおすすめです。
見るだけなら、本番を壊す心配はほとんどありません。それでいて、本番のサーバーやログに毎日ふれることで、新人の中に「普段の姿」が少しずつ蓄積されます。
この「普段の姿」を知っていることが、障害時に異常へ気づく力の土台になります。
ただし、見る権限でも個人情報や認証情報が見えてしまう環境はあります。その場合は、ログのマスキングや閲覧範囲の絞り込みを先に済ませておきましょう。
段階2「触る」は、操作を限定して渡す¶
次の段階では、決められた操作だけを実行できる権限を渡します。
Linuxなら、sudoers で実行できるコマンドを限定するのが典型的なやり方です。たとえば、特定のサービスの状態確認と再起動だけを許可するなら、次のように書けます。
# /etc/sudoers.d/newbie-ops （visudo -f で編集する）
# 新人グループには、webサービスの状態確認と再起動だけを許可する
%newbie-ops ALL=(root) /usr/bin/systemctl status nginx, /usr/bin/systemctl restart nginx
こうしておけば、新人は障害時の一次対応として再起動まではできます。でも、設定ファイルの書き換えやパッケージの削除はできません。
sudo そのものの仕組みは、sudoコマンドの使い方やLinuxのファイル権限の記事で解説しているので、研修の教材として一緒に使ってみてください。
クラウド環境なら、AWSのIAMポリシーで許可するアクションを絞るのが同じ考え方にあたります。書き方はIAMポリシーの作成方法の記事が参考になります。
段階3「変える」は、本人の力ではなく仕組みで守る¶
設定変更やデプロイの権限は、影響が大きい分、渡し方に工夫が要ります。
ポイントは、新人の注意力に頼らず、ミスが事故になる前に止まる仕組みを先に用意することです。作業前の承認、手順書のレビュー、作業中のダブルチェック。こうした仕組みがあれば、新人がミスをしても事故になる前に止まります。
AWSのIAMのベストプラクティスでも、人が使う権限は長く持ち続けるのではなく、ロールを引き受けて一時的な認証情報で使うことが推奨されています。
必要なときだけ権限を借りて、作業が終われば自動で失効する。この形にしておくと、「変える」権限を常に持たせておく必要がなくなります。
段階を上げる条件を、研修の中で決めておこう¶
3段階を用意しても、上げる条件があいまいだと運用が止まります。「そろそろいいか」という先輩の感覚しだいになるからです。
そこで、段階ごとに「次へ進む条件」を研修の到達目標として書いておきます。条件が文章になっていれば、先輩が替わっても判断がぶれませんし、新人自身も次に何を練習すればいいかが分かります。
| 次の段階へ | 条件の例 |
|---|---|
| 見る → 触る | 監視画面から担当サービスの状態を説明できる。ログから直近のエラーを探せる。エスカレーションの基準を言える |
| 触る → 変える | 手順書を読んで、各手順の目的と戻し方を説明できる。検証環境で同じ変更を3回以上、手順どおりに実施した |
| 変える（単独） | 承認つきの変更作業を先輩の立ち会いで数回こなし、振り返りで問題がなかった |
条件の中に「検証環境で練習した」を入れているのには理由があります。本番の前に、壊しても困らない場所で手を動かす経験が必要だからです。
研修用の環境づくりについては、新人インフラエンジニアには「壊していい環境」がいるで詳しく書いています。
また、「触る」段階に進む条件としてエスカレーションの基準を入れているのもポイントです。自分で触れるようになった新人ほど、一人で抱え込みやすくなるからです。この点はエスカレーションを研修で教える方法の記事もあわせて読んでみてください。
権限を渡したあとに、忘れてはいけないこと¶
権限の設計は、渡したら終わりではありません。むしろ、渡したあとの運用のほうが大切です。
定期的に棚卸しをして、要らない権限を戻す¶
新人の担当が変わったり、プロジェクトが終わったりすると、要らなくなった権限が残ります。
これを放っておくと、いつの間にか新人のアカウントが先輩と同じ強さになっています。四半期に一度などと時期を決めて、権限の一覧を見直しましょう。
見直すときは、「今の業務で使っているか」だけを基準にすると判断がぶれません。
操作の記録を残し、責めるためではなく学ぶために使う¶
誰がいつ何をしたかの記録は、事故の調査だけでなく育成にも使えます。
たとえば、新人の作業記録を週に一度いっしょに見返すと、「このコマンドはなぜ打ったの？」という会話が生まれます。これはOJTの材料としてとても優秀です。
ただし、記録を監視や叱責のために使うと、新人は操作そのものを避けるようになります。目的は学ぶことだと、最初に伝えておきましょう。
共有アカウントを使わせない¶
意外と残っているのが、チームで1つの管理者アカウントを使い回す運用です。
共有アカウントでは、誰が操作したのかが記録から分かりません。新人に段階的な権限を設計しても、共有アカウントのパスワードを教えた時点で、すべてが管理者権限に戻ってしまいます。
新人を迎えるタイミングは、個人ごとのアカウントに切り替えるよい機会でもあります。
現場でよく出る疑問に答えておこう¶
この話をすると、研修担当の方から決まって出てくる質問があります。2つだけ取り上げておきます。
ひとつ目は、「夜間の障害対応に新人を入れるなら、最初から強い権限が要るのでは？」という疑問です。
答えは、段階1と段階2で足りる場面が多い、です。障害の初動で新人に求められるのは、状況の確認と定型の一次対応、そして早めのエスカレーションです。設定を書き換えるような判断は、呼び出した先輩が行えば十分です。当番へのデビューの順番は、夜中の呼び出し当番、新人はいつから入れる？の記事で整理しています。
ふたつ目は、「段階を分けると、先輩の手間が増えるのでは？」という疑問です。
確かに最初は、sudoers やポリシーを書く手間がかかります。でも、一度つくった段階の定義は、翌年以降の新人にもそのまま使えます。事故の後始末にかかる時間と比べれば、先に払っておく価値のある手間だと私は考えています。
権限の段階設計を、研修に組み込むには？¶
ここまでの話を、研修の流れに落とすとどうなるでしょうか。
新人研修の中で、Linuxやネットワークの基礎を学ぶ期間は「見る」段階と重ねられます。基礎を学びながら、本番の読み取り専用アカウントで実物を観察する。教科書の知識と本番の姿が結びつきやすくなります。
次に、検証環境での実習期間を「触る」段階の準備にあてます。定型作業を検証環境で繰り返し、条件を満たしたら本番で限定的な権限を渡します。
そして、手順書の読み方や変更管理のルールを学んだあとで、承認つきの「変える」段階へ進みます。
InfraAcademyでは、ブラウザ上でLinuxやネットワークのコマンドを実際に打ちながら学べるので、「見る」から「触る」へ進むまでの基礎固めに使えます。進捗を管理者側で確認できる法人向けのプランも用意しているので、段階を上げる判断材料としても活用できます。詳しくはInfraAcademyの法人プランをご覧ください。
まとめ¶
今日は、新人インフラエンジニアに本番環境の権限をどう渡すかを考えてきました。
最後にポイントを振り返っておきます。
- 最初から管理者権限を渡すと、事故の大きさが本人の注意力しだいになる
- 何も渡さないのは、リスクを消すのではなく先送りしているだけ
- 最小権限は「少なく渡す」ではなく、業務にあわせて渡し、要らなくなったら戻す考え方
- 本番への関わり方を見る・触る・変えるの3段階に分け、上げる条件を研修の到達目標として書いておく
- 渡したあとは棚卸しと操作記録で、権限と学びの両方を育てる
権限の渡し方は、新人への信頼の示し方でもあります。一度に全部ではなく、少しずつ、条件を見ながら広げていく。そのほうが新人も安心して本番に向き合えるはずです。
まずは、今いる新人のアカウントがどの段階にあたるのか、一覧にするところから始めてみてはいかがでしょうか。
