そのセキュリティ対策、意味ないよ

つい最近、
「セキュリティ対策のため、ssh のポートをデフォルトから変更する、ドヤ!」
みたいな記事を読んだ。

でも僕には ssh のポート変更がセキュリティを向上させる場面は思いつかない。
残念だけど、彼の行為は全く意味が無いだろうね。

ポート変更はセキュリティにほとんど影響を与えないし、
あえて言えば、マイナス(セキュリティを弱くする)だろう。

IT セキュリティには
「アタッカーは全てのセキュリティを破る必要は無い」
という大前提がある。

つまり、
システム全体のセキュリティレベルは、その最も低い所で決まる。
個々のセキュリティレベルは、その強さと破られた際の影響で決まる。

で、ssh のポート番号。
お前のシステムではそこがセキュリティレベルの一番低い所なの?

ポート番号を隠すっていう事は、ネットワーク的には外部から通じるんだろうね。
だったら、ポートスキャンすればすぐにバレる。
つまり、「ssh のポート番号を隠す」という対策は極端に弱い。

一方、その影響範囲は普通、無視出来るくらい小さい。
だって、ssh のポートがバレても、アタッカーは何も出来ないから。
パスワードか鍵か知らんが、簡単にはログイン認証が通らないはずだ。

よって、一部の例外を除いて ssh のポート番号はシステム全体のセキュリティレベルに影響を与えない。

じゃあ、「一部の例外って何よ?」っていう話になる。
ぱっと思いつく範囲で言うと、ログイン認証が簡単にできるか、ssh の DOS 攻撃で深刻な影響を受ける場合だ。

いずれにせよ、ポート番号変えている場合じゃないね。

ログイン認証が簡単に出来る?
それって、パスワードが脆弱とか、秘密鍵がどっかで公開されているとか、
そんなとこでしょ?
まずは、そこを何とかしろよ!

SSH の DOS 攻撃で深刻な影響を受ける?
DOS 攻撃が問題になるサーバーはネットワークで守っとけ!

繰り返しになるが、ポート番号の変更なんて超弱い対応方法だ。
そんな超弱い対策に頼らざるを得ないなんて、まずそこがおかしい。

対して、デフォルトポートを変更するっていうのは、実は色々と面倒だったりする。
色々なツールとかセキュリティ対策システムでも、ポートの変更設定を加える必要が有るかもしれない。
そこには一定の工数がかかる。
その工数、もっと大事な所に使えよ。

また、(滅多にないと思うけど、)その設定変更が新しいセキュリティホールや
オペレーションミスを生むかもしれない。

いずれにしても、ポート変更して良いことなんて無いね。

僕は、「デフォルトポートを絶対に変更するな」とは言わない。
ネットワーク的な問題で 80番や 53番を使っている人も居るだろう。
それなら理解できる。
(僕の美学とは反するが)

でも、デフォルトポートを変更はセキュリティ対策にはならない。

今日の僕は少し良いことを書いたので、最後にもう一回記載しておこう。

システム全体のセキュリティレベルは、その最も低い所で決まる。
個々のセキュリティレベルは、その強さと破られた際の影響で決まる。

blog のバックアップ設定

blog のバックアップを設定した。
といっても、mysqldump して s3 にポイするだけだが。

s3curl って便利ね。
「バックアップ」という用途に限って言えば aws client よりもずっと簡単。

ところで、リストアのテストを行っていて気がついたのだけど、wordpress のアップデートが中々の曲者。
管理画面から簡単にできるし、個人ブログの為にいちいちセキュリティアップデート確認するの面倒なので、何も考えずにポチッとやっていた。
でも、バージョンが違うとリストア出来ないではないか!
(いや、別に不思議な仕様では無いけど。)

今にしてバックアップすら行わずにオペレーションを開始した事を激しく後悔しているわけだが、
今後、再インストールとかする時は
wordpress セットアップ -> バージョンアップ -> リストア
という手順になりそう。
バージョンアップの際に「正しいバージョンまで上げる」というのが難点だな。

git flow やってみた

今の会社に入ってから、git flow で開発をしている。
個人的には github flow の方が好きなのだが。。。

git flow と github flow の何が違うのか。
簡単に言うと「どこまでマネージメントするか」、「どこまで個々のプログラマの自主性に任せるか」っていう事だと思う。

当然、github flow の方が git flow よりもプログラマの自主性が高い。
そのため、プログラマからしてみると git flow は管理されている感が強いだろう。
また、git flow だと管理する側が「管理する」という工数が増える。
そういう所が、自分が git flow をあまり好きではない所だ。

一方、git の運用方法はそのプロダクトの品質に間接的に関わってくる。
品質とは、バグ、セキュリティ、応答速度、スケーラビリティ、拡張性、オペレーション、ヒューマンミスの発生しにくさ等である。
そして、システム全体の品質とは、そのシステムの一番低いところで決まることが多い。
バグがなく、応答速度が早くて、スケールして…という一見して素晴らしいプロダクト出会っても、セキュリティがズブズブであればそのプロダクトの品質は低いのだ。

git の運用方法はバグやセキュリティホールの改修速度、リリースバージョンの安定性等に関わってくる。
つまり、プロダクトの品質へ間接的に関わってくるのだ。
(もっとも、過去の履歴がどうであれ即座に修正してしまうスーパープログラマにお任せするのであれば、git の運用方法なんて関係無い。
なので、「間接的」と書いた)

そして、git の運用方法もまた、開発者の最低ラインが全体のレベルに関わってくる。
git flow は開発者間の git の運用レベルに差がある場合、最低ラインを引き上げる良い方法の一つだ。

なので、結論
プロダクトの品質の最低ラインが改修速度やリリースバージョンの安定性であり、
その改善に際し個人技に頼りたくない場合は git の運用方法がプロダクトの品質を決める事がある。
そのような場合、git flow を導入する事でプロダクトの品質が上がるかもしれない。
逆に言うと、それ以外の場合は git flow なんて導入しても無駄な気がする。

個人的には、わざわざ git flow を導入するよりも一定レベルのプログラマと仕事したい。
それが無理なら、運用で縛るよりも教育したい。
そんな事を思いつつ仕事をする今日このごろ。