APNパートナー ソフトウェアパスに関する調査2022
starnishiAPNパートナー ソフトウェアパスの調査することになった経緯
今回、「APNパートナー ソフトウェアパス」を調べることになった理由は、自社の製品を「AWSファンデーショナルテクニカルレビュー(FTR)」を通過させ、AWSパートナーソフトウェアパスの認定を取得することになったからです。
starnishi対象外+α
- AWSパートナーのソフトウェアパスを取得した場合のベネフィットについてはAWSの担当者に聞く予定なのでここでは対象外とした
- 一応、簡単に調べたところによると、従来のAWS ISVパートナーパスは下記のような説明が記載されていた(ソフトウェアパスで調べるとあまり見つからない)
- AWSの顧客に対してAWS営業とともにアプローチする
- パートナーシップを通じてより良い顧客体験、顧客の成功を提供する
- 特典やリソースおよび各種プログラムを活用し、市場投入までのスピードを上げる
ことを目的に設計されています。
starnishiAWS パートナーパス
AWSパートナーが 2021年の AWS re:Invent にて従来のコンサルティングパートナーのタイプ制度からオファリングタイプの制度に変わりました。従来は、企業はコンサルティングパートナーかテクノロジーパートナーのどちらか1つしか選ぶことができませんでしたが、オファリングタイプになるとサービスパスとソフトウェアパス(ISVパートナーパス)として複数同時に取得することが可能になります。
2020年に ISVパートナーパス が発表され、コンサルティングパートナーでもISVパートナーパスを取得することができるようになっていたようです。
今回の新しい制度は、コンサルティングサービスやソフトウェア以外の分野、トレーニング、ハードウェア、ディストリビューションなども含めた全体の領域においてお客様のニーズに応えるための変更のようです。
starnishiAWS Skill Builder に「AWS PartnerCast AWS Foundational Technical Review の進め方」があるのでその動画をまず見る(1h)。
ざっくり知りたい場合は、この記事を参照するだけでも良い。
starnishiワークロード(どういう製品が対象になるのか？)
気になっていたのは、自社製品がソフトウェアパスを受けられるようなワークロードであるかどうか。
この説明を見ると、いろいろなタイプでも受けられるように見えた。
- ①Partner-Hosted タイプ
- 例：
- SaaS など as a Serviceされている
- 例：
- ②Customer-Deployed タイプ -> 例：マーケットプレイス経由での AMI 提供）
- 例：
- お客様のAWSアカウントないのインスタンス、コンテナ上で実行されている
- エンドユーザーに対して提供するシステムの分かりやすい構築ガイド (デプロイメントガイド) が必要
- 例：
- ③それ以外の Others があります。
- 例：
- AWS IoTに接続するIoTデバイス上で動作するソフトウェア
- お客様のオンプレミス環境で動作し、データをAWSに同期するアプライアンス
- 例：
ワークロードのタイプ
FTR ではレビュー対象となるワークロードの種類に応じてチェックする観点が異なります。大きく３つのタイプがあり、①パートナーが自身の保有する AWS アカウントにシステムをデプロイしエンドユーザーにサービスとして提供するような Partner-Hosted タイプ（例：SaaS）、②エンドユーザーが自分たちの保有する AWS 環境でパートナーから提供されているアセットを元にシステムを構築していく Customer-Deployed タイプ（例：マーケットプレイス経由での AMI 提供）、③それ以外の Others があります。
--- 出典: 【Partner-Hosted 編】ファンデーショナルテクニカルレビュー (FTR)でチェックされるポイントとは？
starnishiFTR 要件(ファンデーショナルテクニカルレビュー)
FTR要件について調べて行きたいのだが、Partner-Hostedの資料しか見つからず。
ひとまず、これをベースに調べる・
- Support Level
- AWS Well-Architected Review
- AWS Root Account
- Communications from AWS
- CloudTrail
- Identity and Access Management
- Backups and Recovery
- Disaster Recovery
- Amazon S3 Bucket Access
- Cross-Account Access
- Sensitive Data
- Protected Health Information
- Regulatory Compliance Validation Process
starnishiSupport Level
- ビジネスサポート以上のプランに加入しておく必要がある
- ビジネスサポートの場合、最小で 100.00 USD または 月額利用料に応じる
全ての本番稼働 AWS アカウントにおいてビジネスサポート以上に加入することが要件となっています。 全てのというのは、サービス提供に欠かすことのできないコンポーネントが稼働している、またはアセットを配信しているアカウント全般を指します。例えば、何らかのアプリケーションが動作している環境はもちろん、ユーザーに配布しているインストーラー、ファイル、画像等のデータが保存されているアカウントなども該当します。
starnishiAWS Well-Architected Review
- FTRを受ける前準備としてWell-Architected レビューを実施
- セルフレビューも可能だが理解を深めるために「担当ソリューションアーキテクト」または「 Well-Architected パートナー」と一緒に進めることが推奨
- FTR の要件としては、こちらのレビューを少なくとも年に一回の実施
FTR を受けていただく前準備として、直近で実施した AWS Well-Architected Framework のレビュー結果をご提出いただいています。こちらは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化という５つの柱に沿って、お客様のワークロードの状態を評価し、AWS が推奨するベストプラクティスに向けて改善の計画を立てていくための仕組みになります。また、こちらのレビューには、特定のドメインに特化した追加の評価を行うレンズというものがいくつか用意されていて、FTR に特化した FTR レンズも受けていただく必要がありますので、併せてご実施ください。
Well-Architected レビューは AWS のマネジメントコンソールから利用できる AWS Well-Architected Tool に回答を入力していく形で進めます。全ての質問に回答を入力した後に、PDFとしてレポートを出力してレビュー前日までに弊社のレビュー担当にメールにてご送付いただく必要があります。
starnishiAWS Root Account
AWSの基本的な運用方法に加え、万が一に備えた手順書を用意する。
AWS のルートユーザーの取り扱いに関する項目が複数含まれています。ルートユーザーはその AWS アカウントに対する全ての操作が行える非常に強力な権限を持っています。アカウントを解約して削除するようなこともできてしまうため、取り扱いには注意が必要です。
具体的にはそもそも使用しないことをおすすめします。個人ごとに IAM ユーザーを発行して必要な権限を割り当てる運用にしましょう。
そして、万が一ルートユーザーにアクセスすることができなくなった場合に備えて、ランブック (手順書)を用意してください。何者かに侵害されてパスワードを変更されてしまった、MFA デバイスを紛失または壊してしまったなどいくつかシナリオはありますが、こういった場合どのような対応をとればよいかご存知でしょうか？実際にこのようなケースが発生した場合、事態は急を要します。一刻も早くアカウントの回復を行い被害を最小限に抑えるためには、何を行えばよいかが明確で素早く作業が行える体制を作っておく必要があります。そのために、あらかじめ手順が記載されたランブックを用意し、少なくとも一度リハーサルを行っていただくことを推奨しています。
starnishiCommunications from AWS
- AWS アカウントの代替の連絡先を設定する。
- 代替の連絡先（請求、オペレーション、セキュリティ）を設定しておくと普段の運用が効率的になる
- メーリングリストを使用するのがおすすめ
様々なタイミングで AWS はお客様に通知を行いますが、こちらの代替の連絡先を設定すると、それぞれの役割に応じた通知を受け取ることができます。見逃しがちなポイントですが、代替の連絡先（請求、オペレーション、セキュリティ）を設定しておくと普段の運用が効率的になる場合があります。例えば、請求の連絡先として経理のメールアドレスを設定しておくことで、これまで毎回 AWS アカウントの管理者からメールを転送していた手間をなくすことができるでしょう。
登録するメールアドレスは担当者個人宛でも構いませんが、メールを見逃したり休暇中に緊急で対応が必要なものが届くといったリスクを避けるために、メーリングリストを使用するのがおすすめです。また、言わずもがなですがプライベートで使用している個人のメールアドレスではなく、会社から提供されているドメインのアドレスを使用しましょう。退職した後も連絡が届き続けるといった事態を避けるためです。
starnishiCloudTrail
- AWS ではこの CloudTrail を全てのリージョンで有効化することを強く推奨
- FTR要件としてはCloudTrailのログの保存場所は別アカウント上への保存が必須
AWS ではこの CloudTrail を全てのリージョンで有効化することを強く推奨しています。まずは最低限ログを取っておかなければ、重大なインシデントが発生した際に状況の正確な把握や調査を進めることができず、復旧作業や今後の対策に支障が出ます。普段単一のリージョンしか使っていないというお客様でも、必ず全てのリージョンで有効化するようにしてください。この普段使っていないリージョンこそ目が行き届かず、不正な操作が行われていてもなかなか気づくことのできないポイントになります。
CloudTrail のログの保存場所ですが、同じアカウント内に保存していると FTR の要件を満たすことができません。というのも、アカウントが侵害されたようなケースにおいては、同一アカウント内にログが保存されているとそのログが攻撃者によって削除されてしまうリスクがあるからです。せっかくログを取っていてもこれでは追跡することができないので、CloudTrail を設定しているアカウントとは別のドメインでログを保全することを推奨しています。例えば、監査用のログ集約アカウントのようなものを別途組織で管理し、そちらの Amazon S3 バケットに保存するという方法があります。
CloudTrail
AWS CloudTrail は、AWS インフラストラクチャ全体のアカウントアクティビティをモニタリングして記録し、ストレージ、分析、および修復アクションをコントロールできます。
starnishiIdentity and Access Management(IAM)
- 強力なパスワードポリシーの適用と MFA の設定
- パスワードのローテーションに加え、アクセスキーも９０日を目安にローテーションまたは IAM ロールの利用
- 最小権限の原則
- 権限の見直しを定期的かつライフサイクルにおける重要なイベントが発生した際に実施
- 機密情報の保管はAWS Secrets Manager や AWS Systems Manager のパラメータストアを利用する
- お客様のアカウント情報の暗号化
一般的にセキュリティを向上させるための方法として、強力なパスワードポリシーの適用と MFA の設定は、IAM においても同じく効果的です。忘れずに設定するようにしてください。また、パスワードのローテーションはしているがアクセスキーはずっと同じものを使っているというケースも少なからず見受けられます。アクセスキーも同様に９０日を目安にローテーションする運用を行いましょう。あるいは、システムでアクセスキーを利用している箇所は IAM ロールで置き換えられる可能性が高いです。IAM ロールでは短期間で期限が切れる一時的な認証情報を使用するため、誤って認証情報が漏洩した場合のリスクを最小限に抑えることができます。システム全体でなるべくアクセスキーを使わない設計を試みてください。
各アイデンティティに対して付与するアクセス権限に関しては、最小権限の原則に従って設計してください。実際に使用するサービス、アクション、リソースなどをしっかりと絞り込み、不要に大きな権限が付与されないように注意します。全員に AdministratorAccess や PowerUserAccess のような強力な権限を与えずに、社内でのロール、タスクごとに適切な IAM グループを作成して集中的に管理すると見通しも良くなります。
また、付与されている権限の見直しを定期的かつライフサイクルにおける重要なイベントが発生した際に実施してください。具体的には、メンバーが退職または異動になった際に、アイデンティティの削除やポリシーの変更を定められた運用に従って忘れずに行います。加えて、実施の漏れがないか、ポリシーが現状を反映した最適なものになっているかを確認する定期的な棚卸し作業も必要になります。こちらは FTR の要件としては少なくとも四半期ごとに実施する計画を定めていただくことが求められます。
次にアプリケーション観点の要件になりますが、IAM のアクセスキーやデータベースパスワードなどのシークレットをコードに埋め込むいわゆるハードコーティングは避けてください。このようなシークレットを安全に保存するためのサービスとして、AWS では AWS Secrets Manager や AWS Systems Manager のパラメータストアの機能をご活用いただけます。このようなソリューションを利用してセキュアにシークレットを管理し、アプリケーションレイヤーでのセキュリティ向上に努めましょう。
最後に、エンドユーザー/顧客の認証情報の管理についてです。お客様がログイン時に使用するID、ユーザ名、メールアドレス、パスワードなどの認証情報は必ず暗号化してください。パスワードに関してはハッシュ化も必須になります。アプリケーション側で暗号化するのが難しい場合は、ディスクレベルの暗号化でも問題ありません。お使いのデータベース、ストレージサービスごとに方法は異なりますが、ビルトインの暗号化機能が備わっているものも多いので、詳細は各サービスのドキュメントをご確認ください。
starnishi(引き続き、調査中)
starnishiBackups and Recovery
- RTO (目標復旧時間) および RPO (目標復旧時点) の定義
- 定められた RPO に従って定期的に自動でバックアップを取得する仕組み
- リストアの検証
- FTR の要件としては、定期的かつ大きなアーキテクチャ変更などがあった際にテストを行う運用計画を定義
次のディザスタリカバリ (DR) にも関係しますが、まずサービスが満たすべき水準として RTO (目標復旧時間) および RPO (目標復旧時点) が定義されていないと、適切なバックアップ戦略を決めるのが難しくなります。サービスの性質、機能、データの種類、障害時の影響度などのビジネス要件から総合的に判断して、最初に決めておくことをおすすめします。
そして定められた RPO に従って定期的に自動でバックアップを取得する仕組みを構成してください。この定期的がどれくらいの頻度が適切なのかはお客様のビジネス要件によって異なるため、サービスが満たすべき水準とビジネス要件を改めて見直し、それをシステムの運用に落とし込んでみるのが良いでしょう。場合によっては、ロストしても問題ない重要ではないデータ、後から作り直すことができるデータなどはバックアップを取らないという意思決定が正解かもしれません。
バックアップについて検討が済んだら次はリストアです。バックアップをしっかり取っていてもそれが戻せなければ意味がありません。必ずリストアの検証を行いましょう。本番同様の検証環境などを用意して、できれば同じ程度のデータ量でテストしてみるのがおすすめです。その作業時間が実際に本番でリストアを行うときの目安になります。FTR の要件としては、定期的かつ大きなアーキテクチャ変更などがあった際にテストを行う運用計画を定義していただきます。定期的にリハーサルを行うことによって、本番作業時に迷いなく、ミスなく、素早く作業を行うことができるようになります。新しく入ってきたメンバーの育成という観点も重要です。作業に携わる全てのメンバーを適切に巻き込んでいきましょう。
starnishiDisaster Recovery
- 各社のビジネス要件に沿った DR 対策
- マルチ AZ、マルチリージョンなどのスコープ定義
- スコープに対して有効な有効な DR 構成を設計し、RTO および RPO を定義
- DRのテスト
続いてディザスタリカバリ (DR) です。DR もお客様によってそのスコープは様々ですが、各社のビジネス要件に沿った DR 対策をご準備ください。アベイラビリティゾーンの一つに障害が発生したケースを想定してマルチ AZ 構成を組んでいるお客様もいれば、リージョン全体の障害も想定してマルチリージョンで Active-Standby 構成を用意しているお客様もいらっしゃるかと思います。まずは貴社にとってのディザスタの定義は何か、どこまで備えるのかといった点をご検討ください。
備えるべきスコープが決まったら、それに対して有効な DR 構成を設計し、RTO および RPO を定めます。これは必ずしもエンドユーザーに対して公開している情報である必要はなく、組織内部の目標値でも構いません。RPO については前節のバックアップの頻度によって自ずと決まってくるかと思います。RTO は必ず２４時間以内に設定してください。これを超える場合は FTR の要件を満たすことができなくなります。
最後に DR のテストです。想定したディザスタが実際に発生したと仮定して、サーバーの切り替えやデータのリストアなど必要な作業を実施します。サービスが復旧するまでの時間を計測し、復旧したデータの内容を確認して、ともに RTO と RPO を満たせているか評価しましょう。もし目標を満たせていなければ、構成や目標値の見直しが必要になります。この検証をリストアの時と同じく、定期的かつ大きなアーキテクチャ変更の際に行う運用計画を定めてください。
starnishiAmazon S3 Bucket Access
- FTR では意図しないパブリックアクセスが許可された状態を防ぐための取り組みが求められる
- パブリックアクセスが必要ないバケットには必ずブロックパブリックアクセスを有効化する
- AWS Configなどを利用したアクセスポリシーが変更の検知
S3 バケットのセキュリティについてです。S3 バケットのアクセス制限には大きく分けて2つのパターンがあります。インターネットから誰でもアクセスすることができるパブリックと、特定のネットワーク内または許可されたアイデンティティからのみ利用可能なプライベートです。FTR では意図しないパブリックアクセスが許可された状態を防ぐための取り組みが求められます。
まずは各バケットがパブリックアクセスが必要なのかそうでないのかを整理しましょう。ユーザーからアクセスできるようにしたいといった要件がある場合は、Amazon CloudFront 経由で配信する構成がおすすめです。この方法ではレスポンスの高速化など様々なメリットを受けられますが、オリジンアクセスアイデンティティを使用してアクセスを制限することで、バケット自体をプライベートに保つことができます。パブリックアクセスが必要なケースというのはそこまで多くはないはずなので、これを機に自社の構成を見直してみるのも良いでしょう。
パブリックアクセスが必要ないバケットには必ずブロックパブリックアクセスを有効化してください。こちらを設定しておくことで、意図せぬオブジェクトの公開を防止できます。
また、何らかの理由でアクセスポリシーが変更されパブリックアクセスが可能になってしまうようなことも可能性として考えられますが、それを検知できるようにしておきましょう。これを見逃すとデータの漏洩や、悪意のあるユーザーによるデータの改竄、フィッシングサイト、マルウェアの埋め込みといったインシデントにつながる恐れがあります。気づけないまま数ヶ月経ってしまうというようなことが一番怖いので、最低限のモニタリングとアラートを実装してください。AWS Config による実現方法などがブログで紹介されているのでぜひ参考にしてみてください。
starnishiCross-Account Access
このカテゴリは、エンドユーザーの AWS アカウントに対してアクセスすることがあるソリューションの場合のみ適用される要件になります。そのような挙動がない場合は読み飛ばしていただいて構いません。
- クレデンシャルの受け渡し方法
- × ... エンドユーザーからアクセスキーとシークレットキーを教えてもらいそれをシステムで使用する
- ○ ... IAM ロールを用いたクロスアカウントアクセスの仕組み
- FTR の要件として、AssumeRole には 外部 ID 必須
チェック観点はクレデンシャルの受け渡し方法です。まず最初に思いつくのは、エンドユーザーからアクセスキーとシークレットキーを教えてもらいそれをシステムで使用するという方法かもしれませんが、これにはクレデンシャルのローテーション、認可されていない第三者による不正利用など様々な問題が伴います。詳しくはこちらのブログをお読みいただきたいのですが、代わりに IAM ロールを用いたクロスアカウントアクセスの仕組みを構築してください。簡単に流れを説明すると、エンドユーザーのアカウントで必要な権限を付与した IAM ロールを作成し、サービス提供側のアカウントに AssumeRole を許可する形になります。
この方法であればクレデンシャルを直接やり取りする必要もなく、セキュアにアカウント間の権限委譲を行うことができます。エンドユーザー側の作業が必要になりますので、どのようなことを行えばよいのか手順を記載したガイド、または作業を自動化した AWS CloudFormation テンプレートなどをご提供ください。
FTR の要件としては、ロールの設定方法について注意すべきところがあります。AssumeRole には 外部 ID を必須とします。これは Confued deputy problem と呼ばれる、意図しない第三者によるアクセスを防ぐための仕組みです。必ず事業者側から提供された読み取り専用の一意の外部 ID を使用するようにしてください。
starnishiSensitive Data
- 何を機密データとして特に保護する必要があるか、データのクラス分け
- 機密データに対して適切な保護を検討します。保存時および転送時の暗号化
- 監査実施
機密データの取り扱いに関する要件です。機密データとは何でしょうか？これもお客様によって解釈が異なる概念です。ワークロードの性質に応じて、何を機密データとして特に保護する必要があるか、データのクラス分けを行いましょう。一般的には個人情報 (PII)、保護医療情報 (PHI) などが該当しますが、その詳細な定義も会社によって多種多様です。
クラス分けができたら、機密データに対して適切な保護を検討します。保存時および転送時の暗号化を必ず行ってください。転送に関しては、外部との通信は暗号化プロトコルの使用が必須で、Amazon VPC 内部の通信に関しては必要に応じて使用を検討します。
監査も実施しましょう。誰がいつどの機密データにアクセスしたかロギング、モニタリングし、不正なアクセスが発生していないかチェックします。アプリケーションレベルでのロギングが必要なケースもあれば、AWS サービスの機能で実現できるものもあります。機密データにアクセスする経路全てで包括的なロギングが必要な点にはご注意ください。アプリケーションからデータベースに対するアクセスは監視していても、データベースに直接アクセスすることのできる経路がある場合はそちらの対応も必要になってきます。
starnishiProtected Health Information
- 保護医療情報 (PHI) を取り扱うワークロード
- ほとんどの場合、対象外
こちらは 保護医療情報 (PHI) を取り扱うワークロードで、米国の HIPAA（Health Insurance Portability and Accountability Act) コンプライアンスに準拠する必要のある場合にレビューが必要な要件になります。
本ブログをご覧の日本のお客様にとってはほとんどの場合対象外となる項目かと思いますのでこちらの解説はスキップさせていただきます。
starnishiRegulatory Compliance Validation Process
- サービス提供のために何らかのコンプライアンス、業界標準を取得する必要のあるワークロードにおいては、そちらを遵守するための内部プロセスの定義
最後にコンプライアンスに関する要件です。サービス提供のために何らかのコンプライアンス、業界標準を取得する必要のあるワークロードにおいては、そちらを遵守するための内部プロセスの定義が求められます。例えば PCI DSS、FedRAMP、HIPAA などが代表的なものですが、特に取得が義務づけられているようなものがなければレビューは不要となります。
starnishiまとめ
- 非常に多くの多岐にわたるチェック観点が
- FTR を通過したソリューションまたは製品は、これらの要件を全て満たした AWS お墨付きのワークロード
- セキュリティ、信頼性、運用上の優秀性に関する多くのベストプラクティスを取り入れたお客様が安心して利用できるワークロードという点を製品の付加価値として、プロモーションなどにも活用できる
非常に多くの多岐にわたるチェック観点があったのではないでしょうか？ただ裏を返せば、FTR を通過したソリューションまたは製品は、これらの要件を全て満たした AWS お墨付きのワークロードだということです。セキュリティ、信頼性、運用上の優秀性に関する多くのベストプラクティスを取り入れたお客様が安心して利用できるワークロードという点を製品の付加価値として、プロモーションなどにもご活用いただけるのではないかと思います。そうでなくとも、ここでご紹介したベストプラクティスに準拠することはアーキテクチャや運用体制の改善という観点で全てのお客様にとってメリットのあるものですので、ぜひ社内でも一度レビューをしてディスカッションの機会などにご活用いただければ幸いです。FTR を受けておくべき理由や実際のレビューの雰囲気などを知れるインタビュー記事も公開しておりますのでこちらもぜひご覧ください。
starnishi調査のまとめ
- 認定ソフトウェアの対象となる製品のワークロードは柔軟(Partner-Hosted/Customer-Deployed/Others)
- FTRを受けるだけで、セキュリティ、信頼性、運用上に関する多くのベストプラクティスを学べる