【まず知っておくべき】Wasabiのセキュリティ設定ー続編

前回までのブログでは、初めてWasabi Hot Cloud Storageを利用する管理者の方を対象に、Wasabiを安全に使用するために最低限おさえていただきたいポイントとして、アクセス管理、アクセス権限の設定、なりすまし防止の強化策として多要素認証（MFA）およびSSO（シングルサインオン）との連携、そしてユーザの誤操作や悪意を持ったユーザによるアカウント削除やバケット削除によるデータ消去を防止する仕組みであるマルチユーザ認証（MUA）について説明をしました。

本ブログでは、アクセス管理、多要素認証およびSSO、MUAの各トピックに関する解説および具体的な設定方法について解説していきます。

アクセス管理

アクセス管理は、組織の情報セキュリティポリシーの重要な部分であり、不正アクセスから情報資産を保護するために使用される技術とプロセスのことを指します。 Wasabiのアクセス管理は、ユーザーがバケットおよびその中のオブジェクトにアクセスする際に、認証と認可のプロセスを経ることで適切なアクセス制御を行い、不正アクセスから情報資産を保護することが可能となります。　認証はユーザーの身元検証を行うプロセスを指し、一般にID、パスワードもしくはアクセスキー、シークレットキーを使用します。一方、認可はIAMポリシーを用いて認証されたユーザーがアクセスできるリソースに対する操作権限を定義します。

■　Wasabiの認証と認可

図１：Wasabi コンソール認証画面



図２：認証されたアカウントに対してバケットに対するアクセスおよび操作権限を付与する

IAMポリシーとバケットポリシー

IAMポリシー

IAMポリシーとは認証されたユーザーに対してWasabi バケットおよびオブジェクトに対する操作権限の認可を行うための仕組みです。管理者はIAMポリシーを使用して、個々のユーザーやグループがWasabiバケットやオブジェクトに対して実行できるアクションを制御します。ユーザーはデフォルトではWasabiに対して何も権限が与えられていないため、IAMポリシーをユーザーまたはグループにアタッチすることで、IAMポリシーの権限の範囲内でWasabiに対する操作が可能となります。 同じアクセス権が必要なユーザーが複数存在する場合は、グループに対してIAMポリシーで必要な権限をあらかじめ設定しておき、ユーザーをそのグループに追加するだけで、そのユーザーに間接的に権限が付与されるため、アクセス管理を簡素化できます。

IAMポリシーの実体はJSON形式でWasabi への特定の操作（例: s3:GetObject, s3:PutObject ）の許可・拒否を記述した一連のコードです（図３）。また、IAMポリシーにはWasabiに対するさまざまな操作権限をWasabi側であらかじめ用意したWasabi管理ポリシー（図４）と、利用者が特定のリソースにのみ操作権限を絞りたい場合など、より細かなアクセス制御を行いたい場合にはWasabi コンソールに含まれるポリシーエディタ（図５）を使用してカスタマー管理ポリシーを作成することができます。
IAMポリシーはテキストエディターを用いて作成する事も出来ますが、ポリシーエディタはJSONコードの構文チェックを自動で行ってくれるので複雑なポリシーを作成する際は便利です。　

Wasabiのアクセスを制御する際に利用可能なIAMポリシー、バケットポリシーのサンプルはこちらを参考にしてください。

図３：IAMポリシーの例　（’mybucket’という名前のバケットに対してすべての操作権限を許可するポリシー）

※ポリシーの評価ロジックは常に安全な方に評価するという考え方に基づいており、コード内のEffectにAllowとDenyが共に明示的に宣言されている場合は、常にDenyが優先され、明示されていない場合にはDenyが適用されます。

IAMポリシー要素の説明

図４：Wasabi管理ポリシー

図５：ポリシーエディタ

バケットポリシー

バケットポリシーは、バケットに直接ポリシーを適用し、各種アクションを制御する目的で使用します。IAMポリシーと同様に、JSON形式で記述を行います。バケットポリシーを使用することで、特定のユーザー、IPアドレス、または他のアカウントへのアクセスを制限することができます。これにより、特定のユーザーにのみバケットへの読み取りまたは書き込みアクセスを許可するなど、柔軟なアクセス管理が可能になります。

ユーザーへのバケットに対するアクセス権の割り当ては前述の通り、ユーザーもしくはグループに対してIAMポリシーを個々に割り当てる形でのアクセス制御も可能ですが、バケットが新規に追加された場合などはユーザもしくはグループに割り当てられたすべてのポリシーを変更する必要があるため、バケットレベルでポリシーを設定することで、すべてのユーザに対するアクセス権を一括で管理できポリシーの管理負荷を軽減することができます。

バケットとオブジェクトへのアクセス

デフォルトでは、バケットへのアクセスはプライベートに設定されています。パブリック バケット アクセスが必要な場合は、こちらのKBに記載の通りWasabi サポートに機能を有効にするようリクエストしていただく必要がございます。バケットポリシーのサンプルについてはこちらをご確認ください。　

署名付きURLを利用してオブジェクトにアクセスする

Wasabiのバケットとオブジェクトはデフォルトでプライベートであり、作成したアカウント以外からはオブジェクトにアクセスできません。しかしながら、署名付きURLを使用すると、有効期限付きの特定のURLを介してプライベートバケット内のオブジェクトにインターネット越しにアクセスできるようになります。ユースケースとしては、 限られた時間内での外部ユーザーとのファイル共有や、特定のユーザーにのみ一時的にファイルダウンロードを許可する場合などに有効です。署名付きURLはWasabiコンソールもしくはCLIのいずれの方法でも簡単に作成できます。

Wasabiコンソールから署名付きURLを作成する手順

• Wasabi コンソールから署名付きURLを作成する場合はこちら
• AWS SDKを利用して署名付きURLを作成する場合はこちら

なりすまし防止

多要素認証 (MFA)とは

多要素認証（MFA)は、近年、多方面で利用することがあるため、用語自体はしており、使っている方もいるかと思います。MFAは、英語のMulti-Factor Authenticationの略であり、日本語では、多要素認証と呼ばれている、なりすまし防止のための仕組みです。「多要素」の用語通り、MFAは少なくとも２つの要素を組み合わせて、ユーザーを認証する手法です。どのような要素を組み合わせることが出来るかは、次の通りです。

• 知識要素（知っていること）：例えば、パスワード、PINコードなど
• 所有要素（もっているもの）：例えば、USBトークン、携帯電話へのSMSやメール通知ワンタイムパスワードなど
• 生体要素（有している特徴）：例えば、本人の指紋や顔など

従来の認証では、代表的なパスワードの１つの要素だけで、ユーザー本人かを確認しておりました。パスワードは、本人だけが知っている要素ではありますが、セキュリティ的には、弱く、比較的容易に他人が盗んだりして、本人になりすますことが出来てしまいます。そこで、２つ目の要素と組み合わせることで、なりすましを難しくするように対策を施した手法が、多要素認証と呼んでいます。これにより、他人がWasabiコンソールをアクセスしたり、クラウドストレージへアクセスして、データなどを盗んだりすることを防ぐことが出来ます。

Wasabiでは、多要素認証として、知識要素である「パスワード」と所有要素である「６桁ワンタイムパスワード」を使います。この本人が所有する要素であるワンタイムパスワードを生成するためには、携帯電話などにインストールして持ち歩くことのできるAuthenticatorと言われるアプリケーション（仮想MFAデバイス）を利用します。Wasabiでサポートされる代表的なAuthenticatorは、以下の通りです。

• Google Google Authenticator
• Microsoft Authenticator
• Authy
• Duo Mobile
• Authenticator Plus
• OTP Auth

これらのアプリケーションは、Time-based One-Time Password（TOTP）と呼ばれるパスワードを計算して、表示しています。現在時刻を使って、サーバーと同じパスワードが計算・生成できるような仕組みになっており、一定間隔（一般に30秒）で6桁の数字が表示されます。補足ですが、MFAデバイスには、物理的なものもありますが、こちらは、Wasabiでは、サポートしておりませんのでご注意ください。
MFAアプリケーションの設定や利用方法に関しては、こちら(英語)をご参考下さい。

シングルサインオン（SSO）とは

シングルサインオン(Single Sign On)は、複数のシステムの利用時に必要なユーザー認証を一度に済ませることが可能になる仕組みです。従来は、システム毎に、ユーザーが作られ、システムを利用するための認証も、個別に処理されます。

利用者は、各システム毎のユーザーIDとパスワードを管理する必要があり、負担が掛りますし、セキュリティの観点からでも、パスワードの管理が煩雑になり、リスクが伴います。シングルサインオンの導入により、利用者の負担を軽減することにもつながりますし、システム全体では、セキュリティ強化にもなります。シングルサインオン以下のことが実現できます。

• 管理者は、全ユーザーのアクセスを一元的に管理することができます
• 利用者は、１つのユーザーIDとパスワードで、複数システムへログインできるようになります

Wasabiを利用する上では、重要なものとして、Wasabiコンソールがあり、これにより、クラウドストレージのアカウント管理や、ストレージに関わる様々な設定を行うことが出来ます。このWasabiコンソールへのログインも、シングルサインオンに対応しており、既に企業に導入済みの環境と統合することが出来ます。Wasabiコンソールは、SAML2やOpenID Connect（OIDC）に対応しておりますので、シングルサインオンとの統合により、ユーザーの負担軽減にもなり、セキュリティを向上させることが出来ます。
Wasabiコンソールが、どのようなシングルサインオンのIdPプロバイダーを認定されているか、また利用する場合の手順等は、こちらを参照ください。IdPプロバイダーで提供される、より強固なセキュリティ機能（例えば、アクセス制御など）と組み合わせることで、Wasabi単体だけでの利用よりさらに社内のセキュリティ強化が実現できるようになりますので、ぜひ、実践してみて下さい。

不正な操作・誤操作防止

MUAとは

これまでに紹介した機能は、IT業界においては、広く知られており、様々なシステムやサービスでも対応されていることが多いかと思いますが、Wasabi社が提唱する新しいセキュリティ機能としては、マルチユーザー認証（Multi-User Authentication, MUA）があります。これは、核ミサイルの発射プロトコルに似たコンセプトであり、事前に登録された管理者（Eメールアドレス、最大３人まで）が全一致で承認しない限り指定の操作ができない仕組みです。これは、誤って、重要なユーザーや、データなどが、一人の管理者により、実行されないための仕組みです。
マルチユーザー認証は、Wasabi独自の機能のため、このブログでは、少し詳細に操作手順を見ながら、実際の動作を解説します。

マルチユーザー認証の流れとしては、次のようなものとなります。

• マルチユーザー認証の有効化
• セキュリティコンタクトの追加
• アクティビティ設定
• 管理者による操作トリガー
• セキュリティコンタクトへの承認
• 操作の実行決定（実行または、中止）

ここでは、バケット削除の例を使って、どのような画面イメージなのか、そして、どのような手順でマルチユーザー認証が実行されるかを見ていきます。

１．最初に管理者は、Wasabiコンソールの「セキュリティ設定」から「マルチユーザー認証」を選択し、セキュリティコンタクトを追加します。この際、メールアドレスを指定しますが、このメールアドレスは、必ずしもWasabiアカウントである必要はありません。

２．セキュリティコンタクトにメールが送信されて、一定時間以内に受信者が承認することで、追加したセキュリティコンタクトが正式に承認者として登録されることになります。（「インビテーション承認されました」と表示されて、ステータスを示す〇が青から緑に変化します。）

以上で、承認者の登録が完了します。複数いる場合には、同じ操作を最大３人に対して行います。

３．管理者がバケット削除の操作を実行しようとすると、確認のメッセージとともにセキュリティ担当者の承認が必要である旨の案内があります。

これに同意することで、バケット削除リクエストが対象の承認者に送信されます。

承認者宛てにバケット削除リクエストのメールが届きます。

上図は、アクションをリクエストした人が受信するメール通知です。リクエストが承諾者へ送信された旨のメッセージです。

４．承認者全員が同意して、はじめて、バケット削除が実行されて、完了します。その際のメッセージが以下の通りです。

まとめ

Wasabi Hot Cloud Storageを安全に利用するにはWasabiが標準機能として提供するアクセス管理の仕組みに加え、多要素認証やSSOなど本人認証を強化するための外部認証ツールを組み合わせることで、さらにセキュリティを高めることができます。Wasabi を既にご利用中、もしくは今後導入をご検討中のお客様、そしてWasabiをご提案中のパートナー様の参考になれば幸いです。