サーバー管理を行う場合に、公開サービスを行う場合は、1台だけ管理する事は少なく、
複数台の管理を行う必要があると思います。
クラウドサービスの普及に伴い、サーバーの台数を増やすという事は、ボタンひとつでとても簡単になったため、検証サーバーやstageサーバーなども同時に管理するというのも意外と多いと思います。
セグメント構成
サーバー構成は、vlanやサブネットマスクのセグメント単位でローカル、グローバルという内外の構成を考えなければいけません。
多くの構成で、グローバルに対してローカル環境を横並びに組む事が多いので、とりあえず、2段階の多段構成を基準に考えたいと思います。
多くの場合が、FireWall内のサーバーにアクセスできれば、そのサーバーを踏み台にして、セグメント内の他のサーバーに踏み台でアクセスを行うことが可能になります。
セキュリティとしては、関係者以外がサーバーに入って来られない仕組みを作りつつ、運用担当者は便利に効率良くアクセスを行う必要があります。
セキュリティ対策
多くは「パスワード」「鍵」のどちらかでのログインを許可して運用しますが、2つとも採用するケースもあります。
ただ、多段ログインなどを行う場合はパスワード入力はとても効率が悪くなるので、この辺はポリシーが許す限り、鍵運用のみで行う事をオススメします。
また、会社などでの運用する場合は、鍵に加えて、アクセス元のIPアドレスを許可するhosts設定をする事で第三者からの侵入を禁止し、無差別アクセスからのいたずらを回避することも可能なので、ポリシーをそれに合わせてセットする事も必要ですね。
多段認証をやってみる
sshでのアクセスを行い、上記の構成図を元にweb1を基準に多段認証を行なってみたいと思います。
ここでは、サーバー構成の手順などは省きますので、環境設定に合わせて理解してください。
複数sshアクセス
# local -> web1 -> web2
$ ssh -t user@web1 "ssh user@web2"
この方法を行う場合、
local -> web1
にアクセスする場合は、鍵登録などでパスワードを排除することができますが、
web1 -> web2
のアクセスで、相互web2にweb1からのアクセス公開鍵を登録してある必要があり、逆のアクセスも想定すると、サーバーの鍵管理が台数に応じて膨れ上がってしまうので、都度パスワード入力をするでのあれば問題ありませんが、バッチ処理などでは、パスワード入力が厳しくなってしまうので、デメリット有りというトコロですね。
netcat機能を利用する
# local -> web1 -> web2
$ ssh user@web2.com -o ProxyCommand="ssh user@web1.com -W %h:%p -q"
この方法であれば、localの公開鍵をweb1とweb2にそれぞれ登録しておくことで、web1,web2どちらを踏み台にしても鍵アクセスが問題なく可能になります。
鍵管理もクライアント分を全てのサーバーに登録しておく必要がありますが、バッチ処理をクライアント側でコントロールできるメリットがあるので、オススメです。
ちなみに、ProxyCommandの命令の最後に「-q」をつけないと、
Killed by signal 1.
という返り値が1行必ず入ってしまうので、このオプションで回避しよう。
rsyncを踏み台方式でデータ転送を行う
ローカルの操作PCにあるデータを踏み台サーバーを経由して同じ鍵ファイルでweb2にコピー(転送)する。
# local:~/test.dat -> web1 -> web2:/home/user/test.dat
$ rsync -av -e 'ssh -o ProxyCommand="ssh user@web1 -W %h:%p -q"' ~/test.dat user@web2:/home/user/
rsyncもsshモジュールを利用できる-eオプションがとても便利に使えます。
ほぼ直感でできるんですが、なれないとアンチョコを見ながらでないと、いきなりコマンドを叩き始めるのはキツイんですが、いきなりコマンドできるようになると、結構無敵にできますね。
便利ついでに、rsyncでweb1にあるデータをweb2にコピーする方法を検証しようと思ったんだが、どうやらサーバーに手を入れておかないと難しいかも・・・
次回にやりたいと思います。
0 件のコメント:
コメントを投稿