オンプレミス型とクラウド型のデザインツール：セキュリティの比較と選び方

オンプレミス型とクラウド型のデザインツールを選ぶことは、セキュリティアーキテクチャを決める作業です。ファイアウォールの「内側」か「外側」かだけで、安全性は決まりません。クラウドサービスでは運用負担の一部を提供事業者に任せられます。プライベート環境への導入では、自社でインフラを管理できる範囲が広がる一方、その責任も増えます。組織の脅威モデルに対して、リスク、対策、責任者が適切に対応している方式を選ぶことが重要です。

Pixso のプライベートデプロイメントを検討する場合も、以下のモデルに沿って設定と運用の責任分担を確認できます。

1. デザイン資産の脅威モデルを作成する

デザインファイルには、未公開の製品、カスタマージャーニー、社内システム、API の構想、ブランド資産、本番環境からコピーしたスクリーンショットなどが含まれることがあります。デザインプラットフォームには、コメント、メンバーの識別情報、バージョン履歴、ライブラリ、書き出したデータ、製品の構成が分かるリンクも保存されます。まず、これらの資産を分類し、誰に作成、閲覧、書き出し、管理、削除を許可するかを明確にします。

先に導入方式の好みを決めるのではなく、現実的な脅威を整理しましょう。

• アカウントの乗っ取りや、過剰な権限の付与。
• 公開リンクや、ワークスペースの誤った権限設定。
• 退職・離任した利用者にアクセス権が残ること。
• 未審査のプラグイン、連携機能、フォント、AI サービスによって、データが外部へ送信されること。
• 管理者による不適切な操作や、サービスアカウントの侵害。
• ランサムウェア、破壊的な変更、バックアップの失敗。
• 自社運用コンポーネントにパッチが適用されていないこと。
• 提供事業者の障害、ネットワークの分断、ベンダーサポートの終了。

成果物として、データフロー図とリスク管理台帳を作成します。通常の共同作業に加え、書き出し、バックアップ、サポート担当者のアクセス、テレメトリ、更新、インシデント対応も含めてください。「ファイルが自社サーバーにある」というだけでは、十分なセキュリティモデルになりません。

2. 責任共有の境界を比較する

NIST Cybersecurity Framework 2.0 は、ガバナンスとサプライチェーンのリスクを継続的な責任として扱うため、検討に役立ちます。「統治（Govern）」「識別（Identify）」「防御（Protect）」「検知（Detect）」「対応（Respond）」「復旧（Recover）」の各成果を基準に、どちらの方式も確認しましょう。同じ対策を双方で実施済みとして二重に数えたり、自社とベンダーの間で責任者が不在になったりしないようにします。

3. ID とアクセスの管理を中心に設計する

共同デザイン環境を評価する際は、保存場所だけを見るのではなく、アクセス、共有、アカウントのライフサイクルに関する不備を優先して確認します。デザイナー、レビュー担当、開発者、外部制作会社、ワークスペース管理者、インフラ管理者、サポート担当者のロールを定義します。可能であれば、コンテンツの管理権限とサーバーの管理権限を分離してください。

実際のアクセス制御テストでは、次の項目を確認します。

1. SSO またはディレクトリ連携と、多要素認証の必須化。
2. アカウントの自動作成と、利用終了時の自動無効化・削除。
3. 組織、プロジェクト、ファイル、ライブラリ、リンクの各階層での最小権限のロール。
4. ゲストや契約スタッフのアクセス期限。
5. 書き出し、複製、共有、公開の制限。
6. 監視を伴う緊急時の管理者アクセス。
7. 権限や所有者の変更について、後から確認できる記録。

CISA の Zero Trust Maturity Model は、ID、デバイス、ネットワーク、アプリケーションとワークロード、データを重視しています。サービスが社内ネットワークで動いているという理由だけですべての利用者を信頼するよりも、この考え方で評価するほうが適切です。

端末とブラウザーの管理も重要です。デザイナーは日常的にスクリーンショットを貼り付け、フォントをインストールし、素材を書き出し、共有リンクを開きます。承認済みクライアント、端末のセキュリティ状態、ローカルキャッシュの扱い、ダウンロード先、クリップボードの方針、マルウェア検査、画面キャプチャのルールを定義してください。プラットフォームがプラグインや拡張機能を提供する場合は、許可リスト、管理責任者、権限の審査、更新手順、削除手順を設けます。プライベートサーバーを置くだけでは、正規のクライアントが書き出した内容を未承認の宛先へ送ることまでは防げません。

4. データ、ネットワーク、バックアップ、外部依存を追跡する

画面上のデザインキャンバス以外も棚卸しします。ファイルの内容、画像素材、コメント、フォント、サムネイル、検索インデックス、監査ログ、ID 属性、バックアップ、診断用データ、サポートへの添付ファイルが、どこに保存されるかを記録します。暗号化の範囲と鍵の管理者を明確にしてください。ライセンス確認、テレメトリ、更新、プラグイン、AI、メール、オブジェクトストレージ、サポートに使うすべての外向き通信先を文書化します。

クラウドツールでは、選択したリージョンに保存されるデータの種類と、グローバルに扱われるデータの種類を提供事業者に確認します。プライベート環境への導入では、外向き通信の制御をテストし、必要なベンダーの接続先が文書化されていることを確認します。通信を遮断したときは、予測できる形でエラーになる必要があります。保存、認証、復旧が、説明もなく使えなくなる状態は避けなければなりません。

バックアップには独自の脅威モデルが必要です。必要に応じて変更不能なコピーや別の保護措置を使い、バックアップの管理権限をアプリケーションの管理権限から分離します。内容と設定の両方を復旧できるかテストしてください。目標復旧時点と目標復旧時間を記録し、リストア訓練によって達成できることを確認します。

5. 検知・対応・復旧力を裏付ける証拠を求める

安全なデザインプラットフォームには、導入後に確認できる有用な記録が必要です。認証、アクセス失敗、ロール変更、共有設定の変更、書き出し、削除、管理者操作、サポート担当者のアクセス、設定変更など、記録すべきイベントを定義します。タイムスタンプ、ユーザー識別子、改ざん防止、保存期間、書き出し形式、SIEM 連携を確認してください。

試験導入中にインシデントを想定した検証を行います。侵害されたユーザーの無効化、共有リンクの失効、書き出されたデータの特定、削除されたファイルの復旧、シークレットのローテーション、アップグレード失敗からの復旧を試します。クラウドサービスでは、通知と証拠提供に関する取り決めを確認します。プライベート環境への導入では、自社チームが担当する作業と、ベンダーの支援が必要な作業を確認します。

可用性には、デザイン業務を継続できることも含まれます。想定する負荷の下で、大きなファイル、共有ライブラリ、リアルタイム編集、拠点間の遅延、ローカルクライアントの動作、開発への引き継ぎをテストします。基本的な作業を実行できなくするセキュリティ対策は、回避される原因になります。

測定可能な受け入れ基準を使いましょう。例えば、利用を終了したユーザーの権限を定められた時間内に解除する、すべての外部共有をログから特定する、指定したプロジェクトを復旧目標内に復元する、合意した作業時間帯に重要な更新を完了する、といった基準です。指標を設けることで、対策が文書上にあるだけなのか、日常の運用でも機能するのかを確認できます。

6. Pixso のプライベートデプロイメントに適用する

公式の Pixso プライベートデプロイメントのページでは、シングルノードとクラスター構成、イントラネットとプライベートクラウド、権限管理、メンバー管理、操作ログ、企業向けリソースライブラリ、研究開発管理や DevOps プラットフォームとの接続をカスタマイズする選択肢が説明されています。これらは、自社で管理するデザイン環境の候補として Pixso を検討する材料になります。ただし、実際の導入には、プロジェクト固有のアーキテクチャと責任分担表が必要です。

導入を提案されている正確なバージョンについて、代表的なロールとデータを使ったデモを Pixso に依頼します。受信・送信通信、ID 連携、管理者権限の分離、ログの書き出し、バックアップとリストア、高可用性、更新の提供、脆弱性対応、サポートアクセス、カスタマイズの範囲、データの書き出しを確認してください。そのうえで、Pixso プラットフォームで紹介されている UI デザイン、デザインシステム、コメント、バージョン管理、操作可能なデモ、開発への引き継ぎといった業務の流れをテストします。

7. オンプレミス型とクラウド型のデザイン環境に関する FAQ

Q1. オンプレミス型のデザインツールは、クラウド型より安全ですか？

必ずしもそうではありません。プライベート環境への導入では自社の管理範囲が広がりますが、パッチ適用、監視、バックアップ、復旧、インフラのセキュリティも自社の責任になります。方式の名前ではなく、対策後に残るリスクと運用の成熟度を比較してください。

Q2. 共同デザインで最も重要な管理領域は何ですか？

通常、最初に確認するのは ID とアクセスの管理です。強固な認証、最小権限、アカウントのライフサイクル管理の自動化、共有ルール、後から確認できる管理者の操作記録を整えましょう。

Q3. ファイアウォールがあれば、プライベートなデザイン環境を信頼できますか？

いいえ。社内のアカウント、端末、連携機能、管理者、侵害されたサービスからもリスクは生じます。ゼロトラストの原則を適用し、機密性の高い操作を監視してください。

Q4. クラウド事業者には、どのような証拠の提示を求めるべきですか？

アーキテクチャとデータフローの資料、自社の要件に対応するセキュリティ保証の報告書、ID 管理とログの機能、インシデント時の条件、復旧に関する取り決め、サブプロセッサーの情報、リージョン内に保存されるデータの範囲、サービス利用終了時の手順を求めます。

Q5. プライベートデプロイメントのベンダーには、どのような証拠を求めるべきですか？

サポート対象の構成、ソフトウェア部品表と依存関係の情報、セキュリティ強化の手引き、ネットワーク要件、アップグレードと脆弱性対応の手順、バックアップとリストアの手順、ログの仕様、サポートアクセスの方式、責任分担表を求めます。

Q6. 導入方式の判断は、どのくらいの頻度で見直すべきですか？

アーキテクチャ、製品、規制、脅威、供給元に重要な変化があったときと、定期的なリスク評価の際に見直します。導入方式の選択は、一度の購入で完結するものではなく、利用期間を通じて判断を続ける必要があります。