よくある質問

現在、Amazon Web Services（AWS）、Azure、およびGoogle Cloud Platform（GCP）をサポートしています。

サポートされているリージョンの完全なリストは次のとおりです。

• AWSについては、サポートされているAmazonのリージョンを参照してください。
• Azureについては、サポートされるAzureリージョンを参照してください。
• GCPについては、サポートされるGCPリージョンを参照してください。

これらは、 File Storage Security の管理役割であるStorageStackManagementRoleARNおよびScannerStackManagementRoleARNが File Storage Security の配信および設定後に持つ権限です。

• Scanner Stack 権限については、 Scanner Stack テンプレートで「ManagementRole」を検索してください。
• Storage Stack 権限については、 Storage Stack テンプレートで「ManagementRole」を検索してください。

パフォーマンスの詳細については、 パフォーマンスとスケーリングを参照してください。

詳細については、パフォーマンスとスケーリングを参照してください。

はい。私たちは、 File Storage Security コンソールに接続できる複数のスタックをサポートしています。スタックを配置するには、 スタックの追加を参照してください。

スタックの配信時に、 File Storage Security バックエンドサービスによって、 Scanner Stackにライセンスが設定されます。 Azureのドキュメントによると、Azureの権限が有効になるまでに最大30分かかる場合があります。このエラーメッセージが表示された場合は、数分後に File Storage Security コンソールでスタックを配信してください。

配信情報については、s3：ObjectCreated：* event in useを参照してください。

詳細については、AWSでの オールインワンAll-in-one Stackのデプロイを参照してください。

はい、できます。

テンプレートから配信する場合は、対応する外部IDを取得する必要があります。変更すると、次回のアップデートで古いアップデートに書き換えられます。

Storage Stack のbucketListener は、キューのプロデューサーです。コンシューマ用の暗号化されたメッセージを生成するには、プロデューサにキーの権限が必要です（Scanner Stack）。 Scanner Stack と Storage Stack の両方が、暗号化されたプロセスを正常に動作させるために KMSKeyARNForQueueSSE が必要なのはそのためです。

ここでは、プロデューサとコンシューマのKMS権限について説明します。

プロデューサのKMS権限を設定する

コンシューマのKMS権限を設定する

キューメッセージを暗号化する場合は、 Scanner と Storage Stack の両方で、KMSKeyARNForQueueSSEフィールドに同じ値を入力する必要があります。

Scanner Stack または Storage Stackのいずれか1つに対してKMSKeyARNForQueueSSEフィールドが設定されている場合は機能しません。

FSSの配置に必要な最小限のポリシーについては、次のリンクを参照してください。

https://dsgithub.trendmicro.com/file-storage-security/cloudformation-templates/blob/integration/recommended-deploy-policy.json

はい。テンプレートをダウンロードして、サービスの役割で配信できます。ただし、正しい external-IDを使用していることを確認する必要があります。

スタックの配信パラメータの外部IDが Cloud One アカウントと同じかどうかを確認してください。外部IDを取得します。一致しない場合はスタックをアップデートします。

APIを使用してスタックを配信する傾向がある場合は、ドキュメントサイトを参照して、 でAPIを使用してスタックを配信するための詳細な手順を確認することをお勧めします。

CLIでスタックを配信しない場合は、FSSコンソールにスタックを配信して、プロセスとパラメータが正しいことを確認してください。詳細については、Deploy the All-in-one Stackを参照してください。

CloudFormationが適切な役割を作成しない場合があります。AWSサービスの問題： https://github.com/aws/serverless-application-model/issues/213

推奨される処理がいくつかあります。

別のスタック名を使用してスタックを配信してください。問題が解決しない場合は、失敗した「Scanner Stack」のスタックイベントをエクスポートします。（ Scanner Stackのイベントを取得するには、「Scanner Stack」リソースをクリックする必要があります）。

「ライセンスステータスが無効です」というエラーの一般的な原因の1つは、スタックがAWSにデプロイされているのにFSSバックエンドに送信されず、スタックの有効なライセンスステータスが取得されないことです。

Storage Stackが複数ある場合は、各スタックのStorageStackManagementRoleARNをFSSバックエンドに追加する必要があります。詳細については、スタックの追加を参照してください。

いいえ、公開されていません。 Scanner Stackのテンプレートで定義されたScannerQueuePolicyを確認できます。

AWSの推奨事項については、 https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-best-practices.htmlを参照してください。

キューでSSEを有効にするには、 Scanner Stackのテンプレートを配信するときに、KMSKeyARNForQueueSSEパラメータを使用して設定できます。

AWSの推奨事項については、 https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.htmlを参照してください。

スタックのアップデートでScannerLambdaプロパティを変更する必要がある場合は、カスタマイズしたメモリサイズが上書きされます。スタックのアップデートを実行するときは、カスタマイズしたメモリサイズをCFNテンプレートで指定する必要があります。

テンプレートの Lambdaの設定に特定の変更がない場合、設定は変更されません。変更しない場合、設定は上書きされます。

スタックのアップデートを実行する前に、テンプレートでメモリやタイムアウトなどのカスタム設定を行うことをお勧めします。

Azureリソースのアップデートには時間がかかることがあります。たとえば、役割の割り当てが有効になるまでに最大で30分かかることがあります。その間、BLOBリスナーは検索メッセージを送信できず、エラーが返されます。この状況が発生した場合は、しばらく待ってから、ファイルのアップロードを再度実行してください。

File-stores APIを使用します。詳細については、File Storagesを参照してください。

File-stores APIを使用します。詳細については、File Storagesを参照してください。

GCPサポートによると、バージョン15より前のSafariではGCP Cloud Consoleを操作できません。

Safariはバージョン15以降で使用できます。これが不可能な場合は、GCPの運用にGCP Cloud Shellを使用できます。

これは、GCP Terraformプロバイダの既知の問題です。回避策として、terraform-google-secure-cicdで説明されているコマンドを使用できます。

いいえ、現在の設計では、検索対象から除外する（または含まれる）ファイルを設定することはできません。

AWSには、パフォーマンスを監視するのに十分な初期設定のメトリックが用意されています。FSSで使用されるSQSおよび Lambda を監視するには、AWSドキュメントに従ってください。

CloudWatchを使用したAmazon SQSキューの監視

AWS Lambda関数 メトリックスの使用

静的しきい値に基づいて CloudWatch アラームを作成する

Lambda DLQは、検索タイムアウトの問題とは関係ありません。機能コードエラーまたはサービスエラー（ Lambda スロットリングなど）により処理に失敗したメッセージの保存に使用されます。ただし、この種類のエラーはすでに CloudWatch メトリックで監視できます。

最初に、SQSページでScannerQueueのメトリックを確認します。

[最も古いメッセージのおおよその経過日数]および[表示できないおおよそのメッセージ数]は、メッセージがスムーズに処理されているかどうかを示します。数値が高いままの場合は、ScannerLambdaのスロットリングに関連している可能性があります。

メッセージの量が引き続き多い場合は、ScannerLambdaのメトリックを引き続き確認してください。

スロットルが観察された場合は、[AWS Lambda 関数を操作するためのベスト プラクティス] (https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) に従って、ScannerLambda がメッセージを処理するのに十分な 同時実行数 を持っていることを確認してください。

ScannerLambdaとScannerDeadLetterLambdaのロググループをチェックして、エラーログがあるかどうかを確認することもできます。

File Storage Security は、 スマートスキャン Agentパターン、 IntelliTrap除外パターンファイルファイル、およびIntelliTrapパターンファイルファイルを使用します。

スマートスキャンエージェントパターンファイル（icrc$oth.XXX）は、ヒューリスティック/汎用検出にも使用されます。 RANSOM_HPLOCKY.SM4などの既知のランサムウェアも検出できます。

ファイルの部分的なダウンロードのみが検索時に実行されます。

スマートスキャン （iCRC）は、検索エンジンから受信した入力ハッシュ値のみを使用して暗号化します。この値はファイル全体から計算されるものではありません。

配信されたスタックの機能には、検索イベントを取得して検索結果を公開するための特定の権限が必要です。 Azureのドキュメントによると、これらの権限が有効になるまでに最大30分かかることがあります。この問題を軽減するには、数分後にファイルをアップロードして検索結果を監視します。

いいえ、識別情報のみがトレンドマイクロの Smart Protection Serverに送信されます。

File Storage Security はSSE-KMSを検索できますが、クライアント側の暗号化ファイルは検索できません。

ATSEでは、パスワードで保護されたPDFファイルを検索できます。これらのファイルの正常な検索結果が返されます。

はい。

署名済みURL経由でのファイルの取得に関するネットワークエラーが発生すると、ネットワークモジュール関連のエラーが発生します。

Scannerのログで、 サービスのScannerキューで1時間以上 されたメッセージを検出できます。

Scanner がファイルを取得するためのSASトークンは、1時間のみ使用できます。Scanner は、SASトークンの有効期限が切れているため、ファイルを取得しようとしたときに403エラーを受け取りました。

Scanner アプリの初期設定のインスタンス数は1です。Scanner に大量のメッセージが短時間にアップロードされると、メッセージの処理が遅延することがあります。この問題を軽減するには、関数アプリの[スケールアウト（App Serviceプラン）]ページに移動し、 Azure Functions プレミアムプランに従って[計画のスケールアウトの最大バースト]設定を増やします。最大値は20です。これにより、メッセージがキューに留まる時間が短縮されます。

Azureのパフォーマンスとのスケーリングに関する基本的なパフォーマンステストを確認すると役立つ場合があります。

まれに、クラウド環境でネットワークの問題が発生し、検索が失敗することがあります。このような失敗した検索を再試行するには、検索後処理機能を使用して検索結果トピックに登録することをお勧めします。この機能では、成功したすべての検索をフィルタし、検索に失敗したすべてのファイルの検索メッセージを Scanner に送信して、検索を実行できます。

検索結果を解析するには、 検索結果の形式を参照してください。 Storage Stack のBlobListener関数を使用して、 Scanner に検索メッセージを送信できます。

いいえ。AWSS3の設計では、アップロードリクエストの結果から、アップロードされたファイルが不正であるかどうかを判断できません。

検索結果は、検索の終了後に確認できます。

この場合は、[検索後処理]を実装して、隔離ファイルバケットに不正ファイルを移動することをお勧めします。詳細については、https://github.com/trendmicro/cloudone-filestorage-plugins/tree/master/post-scan-actions/を参照してください。

はい、そのとおりです。S3「fss-scan-result」タグ：「failure」= FSSコンソール：「Scan Error」はい。S3の「fss-scan-result」タグ：「failure」はFSSコンソール：「Scan Error」と同等です。FSS Webコンソールの「検索エラー」は、リスト検索統計APIの結果（ APIレスポンスの「失敗」キー）から発生します。検索されたタグ「fss-scan-result」：「failure」を持つファイルは、失敗した検索の数に含まれます。

失敗した検索については、FSSオンラインドキュメントの「scanner_statusおよびscanner_status_message」セクションを参照してください。

はい。すぐに使用できる、 File Storage Security は、 malicious タグを持つ不正なファイルにタグを付け、それ以上の処理は実行されません。その後、ファイルに割り当てられたタグに基づいて処理を作成できます。

検索後に実行できる処理については、 検索後処理のサンプルコードGitHubページ を参照してください。

ファイルが検索され、不正なファイルであると判明した場合、 File Storage Security はそれを malicious としてタグ付けし、それを S3バケットに返してを検索します。タグ付けの詳細については、 タグの表示を参照してください。

Threat Investigation Portal（TIP）を利用して新しいチケットをAMチームに送信してください。

ScannerLambdaは失敗した検索を1回再試行するため、カウントが一致しない場合があります。これは、 Lambda が最初の検索に失敗した場合、2回目に検索を再試行することを意味します。

Lambda は、両方の試行が失敗した後に、検索失敗に関するメッセージを公開します。ただし、ScannerLambdaを呼び出すたびに、FSSバックエンドに検索結果が報告されます。

トレンドマイクロのバックエンドサービスは、不正プログラムパターンファイル、ライセンス、およびLambdaコードアップデートをプッシュします。

• 不正プログラムパターンは毎日更新されます。
• ライセンスは毎週アップデートされます。
• Lambdaコードは、コードがパッチ適用されるたびにアップデートされます。Lambdaコードの変更は What's New で公開されています。

パターンは1日に複数回更新できます。 Lambda 層としてアップデートされるパターンのサイズは約30〜40MBです。パターンファイルのアップデートは、次のパターンファイルがリリースされるまで、失敗したアップデートを再試行しないことに注意してください。

テンプレートの改訂履歴を確認するには、次のURLにアクセスしてください。私たちのリポジトリGitHub.comで、Blameをクリックして表示できます。

スタックには有効期限はありませんが、最新バージョンを使用することを強くお勧めします。

アップグレードの手順については、 Update stacksを参照してください。

現在、次の3種類のアップデートがあります。

• Lambdaコード。現在、アップデートするストレージとScanner Stackには、3つのLambda関数があります。File Storage Security バックエンドは、Storage Stack内のBucketListenerLambdaおよびPostScanActionTagLambda、およびScanner Stack内のScannerLambdaもアップデートします。Lambdaコードの変更は What's Newに掲載されています。
• Lambda階層の不正プログラムパターンファイルFile Storage Security バックエンドは、最新の不正プログラムパターンファイルをScannerLambdaに送り込みます。
• 検索エンジンのライセンスFile Storage Security バックエンドは、毎週ScannerLambdaに存在するライセンスをアップデートします。Scanner Stackを File Storage Security コンソールから削除すると、ライセンスの有効期限が切れ、4週間後に検索に失敗します。

アップデートされていないスタックを使用すると、アップデートの失敗、データの不一致の発生、サポートの有効期限などの問題が発生する可能性があります。

いいえ、 Lambdaのメモリ設定とログ保持期間はスタックアップデートの範囲内です。

Lambda がFSSによって配置されている場合（PostScanActionTagLambda、BucketListenerLambdaなど）、FSSバックエンドによって自動的にアップデートされます。アップデートは、バグ修正や一部の新機能に関連している可能性があります。ですから避けられません。

Scanner または Storage Stackの Lambda 関数のコードを変更しないことをお勧めします。詳細については、AWSスタックのカスタマイズを参照してください。

いいえ、スタックアップデートをロールバックすることはできません。