こんにちは。インサイトテクノロジーの松尾です！
我々のチームでは、従来 VMware vSphere ESXi イメージのみで提供していた PISO Manager や Insight Database Testing を、AWS Marketplace にて公開し、AWS 上での利用をより簡単に開始できるようになりました。
- AWS Marketplace上でPISO、Insight Database Testingを提供開始
- AWS Marketplace および AWS Data Exchange 上で、 日本法人のソフトウェアベンダー、データプロバイダー、 コンサルティングパートナーが自社のソフトウェアやサービスを提供開始
本ブログでは Amazon EC2 のイメージである AMI の用意にあたり、注意が必要だったことや対処方法などについて、アマゾン ウェブ サービス ( AWS ) から提示されているガイドラインの紹介と、そのうちのいくつかについて、の対処例を紹介させていただきます。
AWS から提供されているガイドライン
AWS からは、AWS Marketplace で AMI を共有するにあたってのガイドラインが提供されており、それに従った AMI を用意する必要があります。
- Amazon EC2 のドキュメントで提示されているガイドライン
- AWS Marketplace のドキュメントで提示されているガイドライン
提供するアプリケーションのセキュリティ的なところについて気にするのはアプリ開発者の責任として、ここではどのようなところに気を付けて AMI を用意する必要があるか、というところを中心に考えます。
これらのドキュメントに記載されていることの概要
アプリ以外の部分で一般的に気を付けることとして、以下のあたりを気にすればよさそうです。
- OS などは最新にしておく
- ec2-user や centos などの、OS 既定のユーザーでのログインを可能にする
- root ログインは無効にしておく
- ssh のキー情報などを削除しておく
- シスログなどのログをクリアしておく
- OS ローカルユーザーのパスワードを設定しない
- アプリケーションのデフォルトユーザーのパスワードを固定ではない値にする
- コマンド実行履歴を削除しておく
はじめに：利用するベースの AMI に注意
イメージ作成にあたって、OS のイメージなどをベースにアプリをインストールなどしていくことになると思います。
例えば CentOS ベースのイメージを利用する場合、CentOS の公式イメージを使用することになると思いますが、その際、AWS Marketplace 由来のイメージを使用しないようご注意ください。
例えば CentOS の場合、以下の CentOS のサイトで公開されている、AMI ID (例えば東京の CentOS 7.8 ではami-0d09d267328197c99)を使用することで、オフィシャルなコミュニティイメージを探すことが可能です。
OS などは最新にしておく
ベースの AMI から Amazon EC2 インスタンスを作成したら、まずは以下のコマンドで環境を最新にし、それから作業を開始しましょう。
sudo yum updateec2-user や centos などの、OS既定のユーザーでのログインを可能にする / root ログインは無効にしておく
Amazon EC2 の Linux 系インスタンスの既定のユーザーは、ec2-user または centos(CentOSのみ) です。元のイメージもそのようになっていると思いますが、このルールにはそのまま従います。他の一般ユーザーを追加して、ssh アクセスを許可しても、AWS Marketplace 公開時は推奨されない形となります。
また、ルートでのログインは無効にしておきます。ベースの AMI がそのような設定になっていると思いますので、設定変更しないようにするとよいと思います。対応が必要な場合は以下のページなどを参考にしてください。
ssh のキー情報などを削除しておく
ssh 関連の情報として削除すべきものとしては、以下のものがあります。
- authorized_keys の情報
- /etc/ssh にある既存の SSH ホストキーペア
authorized_keys は以下のコマンドなどで削除します。これについては、対象の OS に存在する全ユーザーに対して実行する必要があります。
sudo shred -u ~root/.ssh/authorized_keys
sudo shred -u ~centos/.ssh/authorized_keysホストキーペアの削除は以下のコマンドなどで実施します。
sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pubシスログなどのログをクリアしておく
各種ログの中身が残っているとカッコ悪いので、アプリ固有のログや OS のログをクリアします。OS のログ領域(/var/log/)のログは、以下でクリア可能です。
sudo find /var/log/ -type f -name * -exec cp -f /dev/null {} ;OS ローカルユーザーのパスワードを設定しない
提供するアプリケーションのために、ローカルユーザーを用意しておくケースはあると思います。セキュリティポリシーにはパスワードをAMIに含めないよう記載されていますので、ローカルユーザーにパスワードが設定されている場合には、そのパスワードを削除しておきましょう。
sudo passwd -d アプリケーションのデフォルトユーザーのパスワードを固定ではない値にする
上記、OSローカルユーザー同様、アプリケーション自体に既定のユーザーなどが設定されている場合でも、そのユーザーの既定のパスワードが固定の場合には問題になるかもしれません。ただし、OSユーザーと異なり、パスワードナシを許可していないアプリケーションもあるかと思います。
AMI は管理アクセスに固定パスワードを使用できません。AMI は代わりにランダムなパスワードを使用する必要があります。代替の実装としてインスタンスメタデータを取得し、パスワードとして instance_id を使用します。
セキュリティガイドによると、パスワードに instance_id を設定するよう記載があります。instance_id (インスタンスID)は、インスタンスメタデータと言われる実行中のインスタンスの情報です。
- 参考: インスタンスメタデータの取得
インスタンスメタデータには多くの情報が含まれますが、インスタンスIDだけであれば、以下の方法で取得することができます。
curl -s 169.254.169.254/latest/meta-data/instance-id/ここで得られる情報を用い、アプリケーションのパスワードなどの初期化を行います。パスワードを含むアプリケーションの各種設定をインスタンス初回起動時のみに動作させるには、cloud-init の仕組みを使うとよさそうです。cloud-init については多くの紹介記事がありますので適当に Web 検索してもらうとして、ここでは、per-once の仕組みを使います。
per-once は、まさに、Amazon EC2 インスタンス初回起動時のみにスクリプトを実行する仕組みで、以下のような特徴があります。
/var/lib/cloud/scripts/per-onceディレクトリに置いたスクリプトが、インスタンス初回起動時に実行される。- root ユーザーで実行される。
- 各種サービス起動後に実行される。
- 初回起動かどうかは、
/var/lib/cloud/sem/config_scripts_per_once.onceファイルの有無で判断される。(ファイルを削除すれば次回起動時も実行させることができる。)
この仕組みを用いて自身のアプリケーションの初期化を行いましょう。
コマンド実行履歴を削除しておく(この項目は最後に実行。exit するときも気を付ける)
.bash_history など、コマンド操作履歴に相当するものを削除します。こちらについても、centos ユーザーや root ユーザーだけでなく、全ユーザー分のものを削除しておきます。(ちなみに、これは最後に実行しましょう)
shred -u ~/.*historyまた、bash を exit 等で抜けるときには、メモリ上のコマンド実行履歴が .bash_history に書きだされてしまうため、以下のコマンドでターミナルを終了するようにします。
kill -9 $おわりに：AWS Marketplace での公開へ向けて
本ブログでは、AMI を共有(公開)するにあたって検討すべきこと、対処すべきことのいくつかについて紹介しました。
本ブログで記載した記事のいくつかは、AMI セキュリティポリシー内で言及されている「セルフサービス AMI スキャンツール」で自動的にチェックされます。
また、登録申請フォームでは必要事項を入力することになりますが、現時点では全て英語で入力しなければならないことには注意が必要です。AMI の用意以外の部分で AWS Marketplace での公開にあたって必要になったことなどについては、別ブログにてまた紹介させていただこうと思います。
開発メンバー募集中デス。
インサイトテクノロジーにご興味を持たれたエンジニアの方、ぜひご連絡をお待ちしております♪
