雇ったエンジニアに悪意があっても、セキュリティを担保するにはと考えてみた
セキュリティの件でLINEも吊り上げられたりしたので
従業員のエンジニアの中にスパイとか悪意がある人がいたらと妄想したらどう防げるのかを考えてみました。
- 開発エンジニアにどこまで任せるのか？
- Linuxのコマンド履歴改ざんを防ぐ
- DBのアカウントで制御！？
- DBのアクセスはターミナルからのみしたら？
- .envの参照させない権限設定は有効？
- ポートフォワーディングの設定で！？
- sftpサーバーのログも必要
- 色々考えたけども
- 結論
開発エンジニアにどこまで任せるのか？
開発だけさせて運用でのバグや障害対応は新規参入エンジニアにはさせない
という方法が一番一般的で安全ではあるかと思います。
しかし、本番のログやデータを見ながら障害対応を開発した本にに見てもらいたい時もあるはず
本番のDBもさわって、アプリのログを見てもらう権限
それでもって、個人情報などの機密情報にアクセスする時はログを残すという事を考える
Linuxのコマンド履歴改ざんを防ぐ
chattrを使うと.bash_historyなどの履歴を本人が改ざんできないので導入が必要
しかし、OSのコマンドで何をしているのかを確認できても
システムの重要なデータはDBです。
でもアプリケーションの.envでDBのアクセス権を参照できてしまうので
いくらOS階層でのセキュリティをキツくしてもそこまで効果はなさそうに感じてきたかも。。
DBのアカウントで制御！？
本番の.envのアクセス権でwebサーバーのみにする
rootのパスワードを知る人をリーダーなど数人のみする
DBのアカウントをグループではなくて、人単位にする
https://qiita.com/u-chida/items/2dc7fc2e386edde1c421
postgresでいうとlog_statementの値をmod,allにする
とかにすれば肝心のDBのアクセス権を柔軟に設定できるかな。。
誰がDBにどんな変更を加えたか・参照したかが確認できる
.envの参照が制限されているのでアプリになりすましを防げる
という事が可能ですが、実際の現場でこれぐらいに細かい所は見た事ないです。w
log_statementの設定で誰がいつどのクエリーを投げたかがわかりますが
特例のユーザーはロギングしないなどの設定をしないと
アプリからのログも含まれるためログが大量に残ってきてしまいます。
例外的なユーザーはログが残らないかどうか検索したけども、
どうやら無理っぽいでした。
もしいけそうならコメントお願いします。
DBのアクセスはターミナルからのみしたら？
視点を変えて重要機密の情報があるDBはポートフォワーディングしない
というようなポリシーにすればchattrの設定が効いてくるのではと思います。
なぜなら、そうすればエンジニアは踏み台サーバーにログインして
そこからコマンドを叩かないとMySQLに入れないという事なので、
OSのコマンドのログから誰がいつ何をしたかの
MySQLにログインしたかは確認できます。
しかしどういうクエリーかは残せるのかな？
MySQL内のクエリー(コマンド)の履歴も
MySQLなら.mysql_history
PostgreSQLなら.psql_history
で履歴が確認できます。
.envの参照させない権限設定は有効？
.envの中身のDBのパスワードが参照できると
アプリケーションと同じ権限でDBにアクセスできちゃいます。
それが一般的ではあります。
しかし、それではwebサーバ毎に.mysql_historyをチェックしないといけなくなります
でも.envが開発エンジニアに参照できないとなるとそれで生産性は下がります。
監視ツールで自動的にチェックしにいくというだけにしてた方がよさそう
MySQL Workbenchなどのツールが使えない分一部のエンジニアから
「生産性が下がる」など
愚痴を言われるかもしれないので、生産性とのバランスも必要かもです。
あと、phpMyAdminなどのツールを使われたらコマンドの履歴が残らないのでは?
という事も考えられますが、
「phpMyAdminにファイルを置く」
っというコマンド操作が必要になってくるという事になるかと
ポートフォワーディングの設定で！？
少し検索しても
「特定のポートのみポートフォワーディング許可・禁止」
という設定はできないっぽい（ユーザー毎には可能みたい）
no-port-forwarding ssh-rsa HOGEHOGE....
そもそも、フォワーディングが必要な時ってDBのアクセスと
Github ActionとかのWEBからできるCIツールぐらい？
であれば踏み台サーバーには基本的にフォワーディングを禁止させる
デプロイツールでどうしても必要となれば、
踏み台サーバーからのアクセスを拒否する設定をDB側でしておく
という事でうまくいきそう
sftpサーバーのログも必要
sshd_configの設定が
Subsystem sftp /usr/libexec/openssh/sftp-server
だったので
Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO
に変更
設定にエラーがないか確認
sshd -t
sshd: no hostkeys available -- exiting.
エラーが出たので調査
ssh-keygen -A
で解決するらしいのでコマンド実行
権限がないとエラーが出るのでsudoを付ける
エラーもなく解決・再起動
待てよ！？
そもそもsshd -tにsudoつけてなかったからでは？
と重い先ほどの
ssh-keygen -A
で生成されたDSAファイルを削除して
sudo sshd -t
で何のエラーもなし
systemctl restart sshd
sftpの無事設定完了
tail -f 20 /var/log/auth.log
>でログを確認すると実際に参照・書き込みのログが記載されていました。
色々考えたけども
これで悪意があるエンジニアを雇ったとしても全ての行動ログが取得できる
ツール使おうにもSFTPでファイルを置くとそれも履歴が残ります
DBにターミナルからでしかアクセスできない
.mysql_historyに監視をして行が増えたらアラート
機密情報が入っているDBにアクセスする時は上長や他メンバーとのmeetやzoomで画面共有する
これで悪い事はできないはず😎
ターミナルにログで保存されてたら！？
画面キャプチャーツールで画面を保存されてたら！？
と考えるとリモートで100%防ぐのは難しいかなぁ。
いずれにしても機密情報のデータは別サーバーの別DBにしておくにこした事はなさそう
そういった意味でもマイクロサービスは効果を発揮してくるかと思います。
結論
OSのアカウントはグループではなく個人毎に作成
DBのアカウントは個人毎ではなくグループで作成
コンフィデンシャルなDBは踏み台サーバーからのDBアクセスをブロック
踏み台X2を防ぐため踏み台以外のサーバーに
AllowTCPForwarding no を sshd_configに設定
sftpサーバーのログレベルをInfoにして履歴に残す
chattrでDB操作の履歴やLinuxコマンドの履歴の改ざんを防ぐ
前回のベストプラクティスの内容を少し編集しておきます
登録日：
更新日：