Glasswall Halo よくある質問

1. ファイルはREST APIに送信されます。
2. ファイルはクラスター内の永続ボリュームに保存されます。
3. ファイルを処理するためのメッセージが Engine service に送信されます。
4. Engine service は、ファイルを処理するためのメッセージを受信します。
5. そのファイルは persistent volume から読み取られ、その後 Glasswall Engine によって保護されます。
6. その後、保護されたファイルと分析レポートは persistent volume に保存されます。
7. Engine レポートを生成できるように、report extractor にメッセージが送信されます。
8. その後、Engine service から API にメッセージが返送されます。
9. API は Engine からのメッセージを受信し、persistent volume から保護されたファイル、レポート、またはその両方を読み取り、クライアントに対して適切なレスポンスを生成します。
10. その後、API から report extractor にメッセージが送信されます。
11. report extractor はこのメッセージを受信し、分析ファイルと API からレポートを生成します。
12. その後、メトリクスデータが生成されます。
13. 最後に、元のファイル、保護されたファイル、および分析レポートが persistent volume から削除されます。

Glasswall Halo は、PDF、Office ドキュメント（Word、Excel、PowerPoint）、画像など、幅広い種類のファイルをサポートしています。処理されたすべてのファイルの安全性を確保し、元の機能を維持します。

元のファイル、保護されたファイル、および分析レポートは、処理中に一時的に persistent volume に保存されます。persistent volume は、デプロイメントプラットフォームに適したストレージプロバイダーによって支えられています。

• Azure - Azure File Share
• AWS - Amazon Elastic File System (EFS)
• GCP - Google Cloud Filestore
• Oracle - OCI File Storage Service
• オンプレミス (RKE2/OVA) - ローカルディスク

Portal に表示されるトランザクションレポート、ファイル詳細、および処理サマリーは MongoDB に保存されます。

Glasswall Halo は Kubernetes 環境にデプロイでき、Helm chart を活用して簡単にセットアップおよび設定できます。詳細なデプロイ手順はドキュメントに記載されています。OVA 経由でデプロイすることもできます。

エラーレポートがユーザーに返されます。

元ファイル、保護済みファイル、および分析レポートは、file retention policy に従って永続ボリュームから削除されます。保持動作は送信方法によって異なります。

Glasswall Halo では、最大 5 階層のネストされたアーカイブがサポートされています。

Glasswall Halo では、次のアーカイブタイプがサポートされています: Zip、Tar、Zip、7Zip、Rar。

• 許可 – 0
• サニタイズ – 1
• 不許可 – 2

エラーレスポンス内で、Glasswall Halo は特定のシナリオを示す「code」を返します。

エラーコードは HTTP レスポンスコードで始まり、特定のエラーを示す番号が含まれます。
詳細については、API ドキュメントを参照してください。

はい。現在の構成には、平均的なファイルよりも処理が難しいワークロードに対応するための余裕が含まれています。replicas count を増やしてパフォーマンスの向上を確認できる可能性はありますが、同時負荷によって利用可能なメモリが枯渇した場合、エラーが増加する可能性があります。

これは可能であり、その結果、計算リソースの不足を必ずしも招くことなく、node ごとの replicas count を変更できるようになります。

ただし、1 つの node により多くのワークロードを割り当てると、node 障害時の影響範囲が大きくなります。node count を増やすことで、より低いリスクで同じ目的を達成できる場合があります。

CDR プロセスでは元のファイルの中間表現が作成されますが、これは元のファイルよりもはるかに大きくなる場合があります。reserve 値により、複数の大きなファイルを処理できるようにしています。

Glasswall は顧客に対し、1 日あたり一定数のファイルまたは一定量のデータを処理する権利を提供します。

現在、Glasswall は超過利用に対して技術的な制限を設けていませんが、超過利用は契約上禁止されています。

Glasswall Halo にはライセンス管理レイヤーが導入され、entitlement に基づく制限が適用されます。

現在、基本の Helm Chart 構成で暗黙的に定められるものを除き、Engine コールに厳格な上限はありません。

将来のバージョンでは、時間単位および日単位のライセンス容量に合わせてスループットを制御する可能性があります。

1 GB。

一部のファイルは、その構造やモデル表現の要件により、CDR の実行により多くのメモリを必要とする場合があります。

Glasswall は世界有数の CDR ソリューションプロバイダーであり、厳選されたサードパーティコンポーネントを使用しています。

厳格な静的解析、SCA、および IaC スキャンにより、これらのコンポーネントが脆弱性を持ち込まないことを保証しています。
Glasswall は依存関係について透明性を保ち、厳格なセキュリティ基準を適用しています。

Glasswall は、Halo デプロイメントを構成するサービス向けに SBOM を生成しています。これらは要望に応じて提供可能です。

はい、そのとおりです。

Glasswall Halo は安全な環境で実行されるよう設計されており、Glasswall にデータが送り返されることはありません。

Glasswall はライセンス準拠を確認するためにサマリーログを要求する場合がありますが、管理者による明示的な操作なしに顧客データが環境外へ送信されることは一切ありません。

ほとんどのサービスは、CIS ガイドラインに従って強化された Alpine ベースイメージへ移行します。
Alpine は、攻撃対象領域を縮小した、最小構成でセキュリティ強化された Linux ディストリビューションを提供します。

Halo に過負荷がかかると、リクエストキューが蓄積し、429 エラーが返される場合があります。
システムは最終的にバックログを自動的に処理します。

これに時間がかかりすぎる場合で、キューに入っているメッセージが失われても問題ない場合は、キューをパージできます。

kubectl exec -ncdrplatform -it RabbitMQ-server-0 -c RabbitMQ -- RabbitMQctl purge_queue engine-request-queue

Kubernetes と統合された監視ツールにより、パフォーマンス、リソース使用量、健全性に関する可視性が提供されます。 保守と更新は、セキュリティと安定性を維持するために Kubernetes を通じて実施されます。

Glasswall Halo は、暗号化、安全な通信プロトコル、厳格なアクセス制御、そして CDR プロセス自体を採用しており、悪意のあるコンテンツが通過しないことを保証します。

Glasswall は、ソリューションの導入と管理のためのドキュメント、サポートサービス、トレーニングリソースを提供しています。
サポートには、オンラインリソース、カスタマーサポート、コミュニティフォーラムが含まれます。

レイテンシは、ファイルサイズ、種類、複雑さによって異なります。
Glasswall Halo は、遅延を最小限に抑えるためにファイルを迅速に処理できるよう最適化されています。

Kubernetes により、Glasswall Halo は負荷に応じて自動的にスケールできます。
KEDA を使用して、Halo はファイルトラフィックに基づいて CDR サービスインスタンスを動的に調整します。

Keda の詳細を見る