最近あまり時間がとれずこのブログをホストするサーバーのメンテナンスもブログの記事投稿も出来ていませんでした。 今日は久々にSecurity Center でサーバをメンテナンスしていきます。毎日届く Security Center からのスコアも90点まで下がってきたということもありましたし、やっと時間がとれたということもあり。
Alibaba Cloud のコンソールにログインし、 Security Center の状態を確認します。 スコアは 90点、また、12/25 より未対応の脆弱性が9件追加されています。
セキュリティリスクのスコアの内訳は、脆弱性の未対応で6点のマイナス、Alibaba Cloudの設定に関するリスクで4点のマイナスです。
まずは Linux に関する脆弱性の対応から対処します。 Security Center では脆弱性について以下のように具体的にリストしてくれます。 非常にありがたい機能で、これを見るだけで OpenLDAP や FreeType(懐かしい・・）は自分のサーバで 使っていないから急がなくても良いなどすぐにそして簡単に判断可能です。
“Affected Assets”列では影響度をLow / Medium / High で確認可能です。 今回は 使っていない FreeType に関する脆弱性は Medium、それ以外は Low であることが一目でわかります。
修正の対応もこのAlibaba Cloud のコンソールから可能です。 数回のクリックで作業前の自動バックアップからパッチ適用（最新のパッケージのダウンロードと適用）を実行可能です。 今回は、この機能は使わずにOSにログインし、手動でパッチを適用することにします。以前に何度かやってみたのですが正常に動作しないため。その話は過去記事。
サーバにログインし、Update をかけていきます。 普通に Ubuntu でのapt update なので手順は割愛。
修正適用前は 4.15.0.118-generic の Kerne。
修正後は 4.15.0-128-generic の Kernel となりました。（今回の脆弱性は Kernel が対象ではないですが）
再度 Security Center から Verify かけます。未対応の脆弱性は無くなりました。
この時点で Secure Score は 94 まで回復。
次は Cloud Platform Configuration Assessment からの指摘事項の対応です。
1つ目は RAM アカウントで MFA を利用していないユーザへの対応。 個のユーザは過去に日本サイト上のこのブログをホストする ECS インスタンスを国際サイトに移行する際に使った Server Migration Center のアカウントです。 このアカウントは使っていないので無効化し、Whitelistに登録することにしました。
次は ECS インスタンスで SSH Key Pairs が使われていないとの指摘。
実際にはSSH の鍵認証を構成済で、ECS の管理画面上では Key Pair は登録済なんですけどね。 もう1回、Key Pair の bind を実行し、再度 Security Center から Check すると解消されました。 原因は不明。
次の RAM – Board Permissions は簡単に言うと最小特権にした方がよいよ、という指摘。 今回は whitelist にいれてしまいました。
最後は OSS-Versioning です。 ここでいう Versioning は履歴管理、すなわちバックアップとなります。 これは有効にして損はないので有効にします。
以下は設定済の画面ですが、Versioning を有効化しました。
最終的に Secure Score は 100 となりました。 新年を迎える前にサーバをキレイにすることが出来ました。
以上
