ガバガバな権限問題と自動化

先日のCircleCI問題で飛び火した私が関わったシステムに付与されたガバガバな権限問題だが、なんでこんなことが起こるのか考え、何をしないといけないのかまとめてみた。

ガバガバな権限とは

割と人手が足りてないところでありがちな話なのだが、システムやミドルウェアの権限設定が細かく管理されておらず、一つの大きな権限、つまり俗にいう管理者権限を一つで運用しているところが多い。別に管理者権限そのものが悪いというわけではないのだが、特にシステム設計や運用設計をろくにせず、本来は必要のない権限設定を用いて運用していることをガバガバな権限とここでは呼ぶ。

なぜガバガバな権限を設定してしまうのか？

いくつも理由があるのだが、代表的なものを幾つか列挙する。

1. 勉強不足で必要な権限がわからない

2. システム設計・運用設計が十分でない

3. 運用に手が回らない。

なぜ勉強不足になるのか？

僕は一番大きな理由はそのモチベーションだと考える。システムやミドルウェアの権限を設計する際に、僕たちシステムエンジニアたちはお客からの要求や要件をもとにシステム設計をする。しかし基本的にお客から提供されるのは機能要件（つまり何ができればいいか？）がほとんどであり、非機能要件が提供されることはまずない。せいぜい性能要件を出されることがあればいい方で、セキュリティ要件が出てくるお客がいるとしたら、その組織はかなり成熟した組織だ。
こういった背景からプログラマは機能要件を満たすことを中心に勉強を進めていく。やりたいことがあれば、ググって自分のやりたいことに近しいコードを見つけ、それを適宜修正して成果物に組み込んでいくのである。必要となるミドルウェアをインストールするときも、基本は管理者権限での設定になる。READMEやHOWTOには最低限の起動方法までしか書かれておらず、細かい権限設定ができるにも関わらず、その運用設計は利用者に完全に委ねられているのだ。
なお、勉強が十分でないまま最小限の権限で開発や運用をしようとするとどこかしらで権限不足によるトラブルにぶつかる。そういった時に必要最低限の権限をさらに追加するのか、はたまたその新たに必要な権限を持ったIDを利用するのかすればいいのだが、未熟な組織では問題の解決より、がばがばな権限を与えることをしがちである。いやむしろそういったトラブルを避けるために最初からガバガバな権限で運用してしまう。

システム設計・運用設計が十分でない

システム設計・運用設計が十分にならないのは、そもそもその必然性が
意識の高い成熟した組織では、これらが組織内でさらに熟成されていくのであろうが、たいていの組織では一切この目が出ないのである。
おそらくプログラマーやシステムエンジニアならキャリアの早い段階で、最小限の権限を用いた運用をするよう習うものである。しかし未熟な組織にいると前述のように正しい運用をするのに時間と手間がかかってしまうために最小限の権限での運用は疎かになり、そもそもそのような設計すらしなくなるのである。

そもそも細かい権限設計をつかいこなせるか？

細かい権限設計をすればするほど、運用するIDの数も増える。上記はずっとシステムの権限の話をしてきたが、もし人間が何かのミドルウェアにアクセスするのであれば、テンポラリのIDと権限を発行する必要があるかもしれない。これらのことを手で作業をするとなると大変骨の折れる話である。何かのタイミングでたとえばそのIDに紐づくパスワードを一斉に変更しなければならないとなった場合、生産性のない、地味で退屈で大量の作業をすることになる。

それでも権限設計はきちんとしなければならない理由

現在のシステム開発の現場では、全てオンプレミスでシステムを作ることは考えにくい。色々なIaaSやPasS等を活用し、また組み合わせてシステムを組み上げる。またそれらを適切に稼働させるためにも外部のサービスを利用する。
たとえ自前のプログラムやスクリプトが完璧なセキュリティを担保していたとしても、外部のサービスがクラッキングされないとは限らない。実際2023/1/5はCircleCIのセキュリティインシデントにより、僕たちが提供しているサービスもIDとPWを大量に変更する作業に追われ、その後のシステム稼働確認にも追われた。CircleCIに関わる認証権限を絞っていたシステムはそこだけ変更し運用にも影響がなかったが、運用のIDとディプロイのIDが一緒になっていたところはディプロイ作業だけでなく本番運用に影響がないか全般のチェックに追われたのである。

ガバガバな権限問題と自動化

ガバガバな権限で運用しているシステムやサービスはセキュリティリスクだけでなく、可用性のリスクを背負うことになる。それでもガバガバな権限設計をしてしまうのは、

1. 開発者のレベルが低い

2. システムの設計レベルが低い

3. 運用のレベルが低い

ということが挙げられる。1と2は正直、まず組織の意識・行動改革に始まり、実際の設計や実装を積み重ねてノウハウを貯めていくしかない。そして設計・実装のノウハウが溜まり始める頃にやっと運用が大変ということを思い知ることになり、運用のレベルを上げるために何ができるかということを考えていくことになる。

運用作業の自動化

IDと権限の設計などAWSであればTerraformなどで自動化することができる。スクリプトを作ってしまえば環境に合わせてその内容をエディタで修正し、環境に設定をすることができる。
これは今回のトラブルをもとに自分でも調べてみようと思っていることなのだが、このようなセキュリティインシデントが起きた時にパスワードのローテーションをしたい場合、どのような自動化が考えられるだろうか？僕の組織での運用が固まったら、またNoteでご紹介したい。