AppScan 360° 環境のセットアップ

AppScan 360° をインストールする前に、最適なデプロイ環境をセットアップしてください。

AppScan 360° をインストールしてデプロイする環境では、パフォーマンス最適化の前提条件となるツールをいくつかセットアップする必要があります。

デプロイメント・システム
各 Kubernetes クラスター:
- ingress コントローラー
- cert-manager
- メトリック・サーバー
MSSQL Server
Active Directory (LDAP)
ネットワーク
ストレージ
CPU とメモリー
データベース
ブラウザー
ID プロバイダー
画面解像度
アクセス・ポイント

HCL ID

HCL ID により、アカウントに有効なライセンスと、ソフトウェアおよびサポートへのアクセス権が関連付けられます。HCL ライセンス、ダウンロード・ポータル、HCL Harbor へのアクセスに必要です。

HCL ID の作成とライセンスおよびソフトウェアへのアクセスの詳細については、この資料を参照してください。

Linux システム

デプロイを開始するには、Ubuntu Linux システム、バージョン 22.04 以降が必要です。実際のデプロイメントは、リモート Kubernetes クラスターで行えますが、デプロイメントはこの Linux マシンから開始されます。システムに Bash シェルと openssl がインストールされ、指定された SQL サーバーに接続できる必要があります。

ダイナミック・スキャンの場合は、ダイナミック・スキャンを実行するすべてのノードで、カーネル内の inotify インスタンス数を増やします。

fs.inotify.max_user_instances=524288 を /etc/sysctl.conf に追加します。
ノードをリブートして、変更を有効にします。

ローカル・コンテナー・サービス (Docker)

Docker は、イメージをリモート・レジストリーにプッシュできるローカル・コンテナー・サービスです。これは、HCL ライセンスおよびダウンロード・ポータルでダウンロードしたアーカイブ・ファイルから ASCP と Omnia/AppScan 修復アドバイザリーをインストールする際に必要となります。

Kubernetes クラスター

このクラスターは、ASCP エージェント・コンテナーが存在する場所であり、活用される場所です。

ReadWriteMany をサポートするストレージ・プロバイダーが必要です。longhorn のようなカスタム・ストレージ・プロバイダーを使用する場合は、ReadWriteMany をサポートしていることを確認します。

Kubectl

Kubectl は、リモート Kubernetes クラスターとの通信に使用されます。

Kubectl のインストールおよび構成の詳しい手順については、こちらをご覧ください。

Helm 3

Helm 3 は、Kubernetes アプリケーションを容易に構成および使用できるようにするための一連のリソースです。

Helm CLI のインストールの詳しい手順については、こちらをご覧ください。

Linux とコンポーネント・サービスの間の通信の確認

Kubernetes の接続性を検証するには、次を実行します:

> kubectl version

または

> kubectl get nodes

Docker の接続性を検証するには、次を実行します:

> docker version

Helm の接続性を検証するには、次を実行します:

> helm version

ingress コントローラー

HTTPS バックエンド・プロトコルをサポートする ingress コントローラーをデプロイします。

推奨される ingress コントローラーは NGINX (最新バージョン) です。ただし、適切な ingress コントローラーがクラスターに既に存在している場合は、新しいコントローラーをインストールする必要はありません。

コントローラーは、以下の要件を満たしている必要があります。

proxy-body-size: 2g
proxy-connect-timeout: 3600
proxy-read-timeout: 3600
proxy-send-timeout: 3600
enable-access-log-for-default-backend: true
ssl-redirect: true
use-http2: true
use-forwarded-headers: true
compute-full-forwarded-for: true

cert-manager

Cert-manager をインストールして構成します。

MSSQL

MSSQL はリレーショナル・データベース管理システムです。

Active Directory (LDAP)

Active Directory は、ネットワーク内のすべてのユーザーとコンピューターの認証と承認を行い、ネットワーク・アクセスのためのセキュリティー・ポリシーを割り当てて適用します。

重要: AppScan 360° バージョン 1.1.0 以前からアップグレードする場合、LDAP 構成をそのまま再利用することはできません。インストールする前に、すべての LDAP パラメーターが AppScan 360° バージョン 1.2 の要件を満たしていることを確認する必要があります。

ネットワーク

ネットワークは暗号化されていて、ネットワーク・ポリシーをサポートしている必要があります。

重要: クライアントと AppScan 360° の間の通信用にインストールする証明書として、信頼できる証明書を使用することを強く推奨します。信頼できる証明書がない場合、クライアントと AppScan 360° の間の通信は信頼できないものになります。クライアントは証明書をクライアントの JRE キーストアにインポートできます。ただし、このオプションは、Static Analyzer コマンド行ユーティリティー (SAClientUtil) を AppScan 360° から自動的にダウンロードする静的分析クライアント (Azure プラグインなど) では機能しない可能性があります。

ストレージ

AppScan 360° は、2 種類のストレージを使用します。必要なストレージ・スペースは、スキャンの回数とスキャン対象のアプリケーションのサイズによって異なります。ガイドラインとして、1 回のスキャン実行に必要なストレージの平均サイズは、以下のとおりです。

MSSQL サーバー DB ストレージ: 150 キロバイト
ファイル・ストレージ: 3 カ月

スキャン実行数あたりの推定ストレージ:


スキャン実行数	1,000	100,000	1,000,000
MSSQL サーバー・ストレージ	150 メガバイト	15 メガバイト	150 GB
ファイル保管	10 ギガバイト	1 テラバイト	10 テラバイト

データベースとファイル・ストレージの両方に推奨される最小ストレージ・サイズは、ログの一時保管用にそれぞれ 200 GB です。

注: ストレージは、ポッド間で暗号化および冗長化され、かつ共有可能になっていて、RWX (ReadWriteMany) アクセス・モードをサポートしている必要があります。

古いスキャンを手動で削除すると、スペースを節約できます。

CPU とメモリー

CPU とメモリーの要件は、ユーザー数と予想されるワークロードによって異なります。

デフォルトでは、Kubernetes ジョブはスキャンごとに最小リソースを割り当てます。場合によっては、ユーザーのアクティブな状態、使用する自動化の程度、アプリケーションのサイズ、スキャンの頻度などの要因によって、スキャンを正しく実行するためにより多くのリソースが必要になることがあります。ポッドは、リソースが使用可能であると仮定して、定義された最大リソースまでスケールアップしようとします。スケールアップに十分なリソースがない場合、一部のスキャンが失敗する可能性があります。

最大限の成功のために、必要な場合にシステムをスケールアップできる十分なリソースを用意してください。リソースの割り当ては、同時スキャンの数に基づいて決定されます。

ASCP のリソース

ASCP のみを実行する場合:


		メモリー	CPU (vCore)
ASCP
	最小	42 ギガバイト	10
	最大	48 ギガバイト	12

注: ASCP リソースは一定であり、スキャンで必要なリソースに加えて使用されます。

リソースのスキャン中

スキャンの実行時には、追加のリソースが必要になります。


		メモリー	CPU (vCore)
動的分析スキャン: 単一のスキャン
	最小	3 ギガバイト	2
	推奨	4 ギガバイト	5
動的分析スキャン: 5 件の同時スキャン
	最小	15 ギガバイト	10
	推奨	20 ギガバイト	15
動的分析スキャン: 10 件の同時スキャン
	最小	30 ギガバイト	20
	推奨	40 ギガバイト	30
静的分析スキャン: 単一のスキャン
	最小	16 ギガバイト	2
	最大	28 ギガバイト	6
静的分析スキャン: 5 件の同時スキャン
	最小	80 ギガバイト	10
	最大	140 ギガバイト	20
静的分析スキャン: 10 件の同時スキャン
	最小	160 ギガバイト	20
	最大	280 ギガバイト	40

さらに同時スキャンを追加するには、十分な追加リソースが必要です。

上記で単一スキャンに対して示されているスキャニング・リソースに、予想される同時スキャン数を掛けて、ASCP のリソースに加えてください。
次に例を示します。
- 5 件の同時スキャンの最小リソースは、122 GB のメモリーと 20 CPU です (ASCP 用に 42 GB + スキャン用に 80 GB、ASCP 用に 10 CPU + スキャン用に 10 CPU)。
- 12 件の同時スキャンの最小リソースは、234 GB のメモリーと 34 CPU です (ASCP 用に 42 GB + スキャン用に 192 GB、ASCP 用に 10 CPU + スキャン用に 24 CPU)。
ASCP のインストール時に、発行された AppScan 360° ライセンスの数が十分であることを確認してください。
Kubernetes の構成とリソースの可用性は、同時に開始して実行する複数スキャンの数が許容されるものになるように定義します。
25 件を超える同時実行数はお勧めしません。

各サービスの最大数は、予想されるピーク・スキャン・ロード・プロファイル、つまり、送信されるスキャンのピーク数、ソース・コード/バイナリーのスキャンの比率、および IRX のスキャンの比率によって異なります。これらが不明なために、最初の配置では最適な構成を定義できない場合があります。HCL AppScan 360° の構成は、実際のスキャン負荷に基づいて調整できます。

注: スキャンを実行するには、そのスキャンに必要なリソースを単一ノードで使用できる必要があります。静的スキャンに推奨されるノードには、少なくとも 28 GB の RAM と 4 つのコアが必要です。動的スキャンに推奨されるノードには、ログの一時保存のために少なくとも 4 GB の RAM、3 つのコア、200 GB のディスク領域が必要です。

データベース

データベースのインストール、管理、バックアップ、メンテナンス、およびライセンスは、ユーザーの責任です。
MSSQL Server 2019 以降がサポートされています。
HCL AppScan 360° をインストールする前に、1 人のユーザーに db_creator 許可を設定してください。

ブラウザー

AppScan 360° は、以下のブラウザーの最新バージョンをサポートしています。

Chrome
Safari
Edge
Firefox

ID プロバイダー

インストール・プロセス中に 2 人のローカル・ユーザーが作成されます。

	管理者	アプリケーション・マネージャー
ユーザー名	Admin	User
パスワード	Admin12!	User12!

追加のユーザーをオンボードする場合、HCL AppScan 360° は Microsoft Active Directory を必要とします。

画面解像度

HCL AppScan 360° の推奨画面解像度は、1920 x 1080 です。

アクセス・ポイント

コンポーネント	Ingress URL
ユーザー・ポータル	`https://<CK_CONFIGURATION_DISCLOSED_SITE_URL>`
ユーザー API	`https://<CK_CONFIGURATION_DISCLOSED_SITE_URL>/api`
ユーザー API (Swagger)	`https://<CK_CONFIGURATION_DISCLOSED_SITE_URL>/swagger`

注: DNS サーバーで Ingress 指定 IP を使用して Ingress FQDN を公開する必要があります。