セッションごとに数ページ（httpsを介して実行）に機密データを保存する必要があります。
セッションストアがバックアップストアと同じように設計されているため（主にサービス呼び出しを行い、セッションをロードする）、セッションオブジェクトを使用できません。セッションが再開された場合、つまりセッション内のキーが存在しない場合は、サービスを作成してセッションを再設定します。
したがって、機密データを入力したユーザーの場合、このデータをページ間で転送する必要があります。現時点では永続的なストアがないため、残されたオプションはこれらの機密データをViewstateに保存することです。
1）データを暗号化してViewstateに保存する必要があります（ただし、推奨されません-秒とパフォーマンスの影響）または2）データをシリアル化可能なクラスに保存してViewstateに保存する必要がありますか？（パフォーマンスへの影響があるため、再度お勧めしません）
何か意見はありますか？
セッションごとに数ページ（httpsを介して実行）に機密データを保存する必要があります。
ViewStateは、ページレベルで設定および維持されます。異なるページリクエスト間で実行することはできず、現在のページのポストバックのみを実行できます。あなたが本当にあなたがポストバックではなく「数ページにわたって」データを運ばなければならないことを意味すると仮定します。
機密データをCookieに保存する可能性がありますが、これにはセキュリティ上のリスクが伴います。
機密データをサーバー側のデータストア（xmlファイル、データベースなど）に保存し、データのキーをクライアント側のCookieに保存することもできます。もう少し安全です。
まあ、一般的な答えはそれをしないでください！ビューステートは暗号化されていますが（暗号化できます）、機密データを保存するようには設計されていません。その理由は、ビューステートデータがサードパーティによって取得され、後で復号化される可能性があるためです。
しかし、それはあなたがそれをすべきではないという意味ではありません... :-)まず、あなたの接続はhttps経由であるため、送信するものはすべてすでに暗号化されています。これは、機密データの取得が非常に困難になることを意味します。サードパーティが機密データを盗んだ場合、最初に接続を復号化し、次にビューステートを復号化する必要があります。したがって、攻撃者が他のアプローチを使用してデータを取得する方がはるかに簡単です（ユーザーをだます、フィッシングなど）。
したがって、データの安全性のために、暗号化されたビューステートにデータを保存し、httpsを使用するだけで十分なはずです。
1）と2）のどちらを選択しても、パフォーマンスにまったくまたはほとんど影響がないはずです。オブジェクトをビューステートに保存すると、オブジェクトはシリアル化されてから保存されるため、どちらのアプローチを選択しても、データはシリアル化されます。データを格納するクラスを設計することは、クリーンなアプローチのように聞こえるので、それをお勧めします。機密データを暗号化されたフィールドに格納するクラスを作成して、機密情報の取得をさらに困難にすることもできますが、パフォーマンスがさらに低下します。
2.0を使用している場合は、ビューステートを暗号化できます。このChannel9の記事を参照してください。AESは、米軍および連邦政府にとって十分な暗号化です。DESは数時間で解読される可能性がありますが、AESはAESを解読するのに150兆年（2001年のハードウェアを含む）を必要とします。より高速でより分散されたハードウェアを使用しても、悪意のあるユーザーがビューステートをクラックするために必要なリソースの価値はありません。マシンキーがどういうわけか安全でないと思わない限り、セキュリティリスクの暗号化がもたらすものはわかりません。
パフォーマンスに関しては、機密データを含むビューステートは、貴重なメモリサーバー側にデータを保存するか、貴重なCPUサイクルを使用してデータを暗号化するか（特に「サーバー側のビューステート」を構成できる2.0）のトレードオフです。作業負荷と特定のハードウェアを使用して経験的な証拠を収集し、実際のトレードオフを確認することをお勧めします。ビューステートではなくセッションに状態を保存するようにアプリケーションを設計するのに遅すぎない場合は、安全（サーバー側）でサーバー側のメモリをあまり使用しないSqlSessionStoreを検討することもできます。
1.1を使用している場合、1.1からのビューステート（または2.0からの暗号化されていないビューステート）のデコードは簡単な作業であるため、機密データをビューステートにすることに関するすべての落胆的なアドバイスは100％正しいです。
これを viewstate で安全かつ確実に動作させるためのコードを記述するのにかなりの労力が必要であることを考えると、代わりにサーバー側のデータ ストアを作成するだけにその時間と労力を費やすことを検討する必要があります。
すでに明確に定義された必要性があり、それを実装するための労力は、おそらく代替のカスタム ビューステート メカニズムと同じかそれ以下です。違いは、永続ストアがアプリの他の場所で、または後で他の機能の開発中に価値を持つ可能性があることです...一方、viewstate メカニズムは、1 つの要件の直接の範囲外に価値を追加しません。
単純な MS Access データ ファイルをサーバーにドロップするのはかなり簡単です。XML またはテキスト ファイルをドロップして、それらにデータを書き込むこともできます。SQL Express、VistaDB、さらには MySQL などの軽量リレーショナル ストアにアクセスすることは、それ以上の労力ではありません。
シリアル化可能なクラスを使用するかどうかに関係なく、ビューステートに適度な量のデータを格納することは、パフォーマンスの問題にはなりません。
ビューステート内のデータ値を保護するには、暗号化を使用する必要があります。繰り返しになりますが、パフォーマンスは、適度な量のデータでは問題になりません。ビューステート暗号化を有効にする方法の詳細については、このページを参照してください。
機密データは簡単に逆シリアル化できるため、ViewStateに保存しないでください。
しかし、あなたはまた、ページがhttpsを介して実行されていると言ったので、答える必要がある質問は次のとおりです。データの機密性は誰ですか？ページにアクセスしているユーザー？次に、それを暗号化する必要があります。
そうでない場合は、httpsを使用しているので大丈夫です。
開発者が起こりうるとは考えていなかったことが原因で、あらゆるセキュリティ リークが発生しているため、ビューステートに機密情報を保存することはないと思います。
暗号化されているかどうか。
ユーザー環境を制御することはできないため、この「機密」情報に本当にアクセスできるものを制御することはできません。