Cloud renderingの仕組み：技術解説

クラウド印刷 Cloud renderingでは、ドキュメントがプリンター固有のデータになる工程をユーザーのデバイスやPrint serverからクラウドサービスへ移します。ユーザーのアプリケーションがドキュメントを生成すると、そのドキュメントはクラウドへ送信されます。クラウドは出力先プリンターに適したdriverを選び、そのプリンターの実際の機能に合わせてジョブをレンダリングし、印刷可能なデータをローカルのConnectorに送信します。Connectorがそれをプリンターに渡します。

エンドポイントには一切printer driverが保持されません。この一点がこの記事の残りすべての前提であり、Cloud printingと単にブラウザー経由でPrint serverを管理することとの決定的な違いです。

なぜレンダリングの場所が重要なのでしょうか？

レンダリングは特定のプリンターに関する知識を必要とする唯一の工程です。したがって、レンダリングが行われる場所にdriverが存在する必要があります。

従来の環境では、レンダリングはエンドポイントかPrint server上で行われます。つまりdriverはエンドポイントかPrint server上に置かなければなりません。ITチームが印刷に関して嫌う問題のすべてはここから生じます。driverの展開、driverの競合、Windowsアップデートごとのdriverテスト、print spoolerがSYSTEM権限でdriverを読み込むこと、そして主にdriver配布のために存在するPrint serverなどです。

レンダリングをクラウドに移すと、driverもクラウド側に移ります。driverライブラリは引き続き存在しますが、それは皆さんが所有し管理する任意のマシン上にはもう置かれません。

Cloud renderingのパイプラインはどのような段階で構成されていますか？

Cloud renderingは、送信（submission）、識別（identification）、レンダリング（rendering）、配信（delivery）、出力（output）の5段階で実行されます。

第1段階：送信

ユーザーは Windows、, ChromeOS、, macOS、iOS、または Androidから印刷します。デバイスから送られるのはドキュメントとジョブのメタデータ（どのプリンターか、部数、両面、カラーなど）です。まだプリンター固有のデータストリームではありません。デバイス上にはそれを作る方法がないからです。

第2段階：識別

クラウドプラットフォームが出力先プリンターを特定し、その機能（ページ記述言語、用紙サイズ、両面対応、使用可能トレイ、仕上げオプション、カラー処理など）を参照します。

第3段階：レンダリング

ここが最も重要な工程です。プラットフォームはクラウド上のdriverライブラリから該当するdriverを選び、対象デバイスに対してジョブをレンダリングします。ezeepはこの目的のために6,000種類以上のメーカー別driverライブラリを維持しています。出力されるのはプリンターが直接処理できるデータであり、最小公倍数的な近似ではなくプリンター本来の機能を反映した印刷が可能になります。

第4段階：配信

レンダリング済みジョブは ezeep Hub （プリンター設置場所）に配信されます。Hubはクラウドへの持続的な アウトバウンド専用 接続を維持しており、インバウンドを受けるのではなくジョブを自ら取得（プル）します。したがってファイアウォールでポートを開放する必要はありません。

第5段階：出力

Hubは印刷準備済みデータをローカルネットワークまたはUSB経由でプリンターに渡します。データはプリンターが理解する形式なので、プリンターは即座に処理します。デバイス側にクラウド機能やファームウェア変更、Mopria認証は不要です。

Cloud renderingはCloud-managed printingとどう違うのでしょうか？

この区別は購入者が最も誤解しやすい点で、ベンダー側にはそれを明確にする動機があまりありません。

Cloud-managed printing とは、Print serverやユーザーのマシン上のdriversが依然として存在し、それらをウェブコンソールから管理する形態を指します。print spoolerは動き続け、driversはエンドポイントに展開されます。Windowsマシンにはパッチ適用が必要なままです。クラウドに移ったのは管理インターフェースだけです。

Cloud-rendered printing とは、レンダリング工程自体がクラウドで行われることを意味します。したがって印刷経路にPrint serverもエンドポイントのdriverも、ローカルのprint spoolerも存在しません。

見分けるテストは一つだけです。 プリンターがインストールされ、print spoolerが稼働しているWindowsマシンはまだありますか？ もし「はい」なら、それがベンダーが何と呼ぼうとPrint serverであり、皆さんはそのパッチ適用責任、その障害モード、そのCVEへの露出を引き続き負うことになります。

これはMicrosoft自身の製品にも当てはまります。Universal PrintがPrint serverを不要にするのは、ネイティブに対応するプリンターのみです。それ以外はUniversal Print connectorが必要で、これはプリンターをローカルにインストールした常時稼働のWindowsマシン上で動作し、Windowsのprint spoolerに供給します。名前が変わっただけのPrint serverです。

Cloud renderingは印刷環境から何を取り除くのでしょうか？

レンダリングがエンドポイントからなくなると何が不要になるかを追ってみましょう。

セキュリティ上の影響は正確に述べる価値があります。 Microsoftは、同社のセキュリティレスポンスセンターに報告されたWindowsのセキュリティ問題の9 %が印刷スタックに起因するとしています、そして2021年のPrintNightmare以降、約53件のprint spoolerに関する脆弱性が公開されています。印刷経路からprint spoolerを除外することは、その脆弱性クラスに対するパッチ適用ではなく、クラス自体を取り除くことになります。

Windows Protected Print により、これは理論上の問題ではなく短期的な現実的課題になっています。WPPはエンドポイント上のサードパーティdriverをブロックし、Mopria認証済みプリンターでしか動作しません。Cloud-renderedなアーキテクチャでは、Hubがデバイスの認証状況にかかわらず印刷準備済みデータを配信するため、プリンターがWindowsとIPPでネゴシエートする必要はありません。未認証の複合機、ラベルプリンター、古いデバイスも引き続き動作します。

Cloud renderingのトレードオフは何ですか？

トレードオフは2つあり、ごまかさずに明記すべきです。

接続性。 Cloud renderingはクラウドへの接続を必要とします。インターネットがダウンすれば印刷に影響が出ます。これはこのモデルに固有のもので、Microsoftを含むすべてのクラウド印刷サービスに当てはまります。Microsoftのドキュメントにも、デバイスがインターネットに接続されていなければユーザーは印刷できないと明記されています。回線が切れたときに印刷がどれほど重要かによって許容可能かは変わりますが、どのベンダーにも問いただすべき正当な質問です。

ジョブが社外に出る。 ドキュメントはクラウドでレンダリングされるため、クラウドへ送られます。印刷データは転送中にTLSで暗号化され、隔離されたテナント環境でレンダリングされます。データ所在地要件が厳しい組織にとっては、これはセキュリティレビューで後から発覚する事項ではなく、事前に意図的に議論すべき点です。

どちらも導入をやめる理由にはなりません。どちらも、何を選んでいるのかを理解するための理由です。

Looking to Move to the Cloud?

Find out how.

Watch Our Demo