世帯のメンバーごとに個別のHome Assistantアカウントを使用し、共有アカウントは、用途と所有者が文書化された固定の共有デバイスに限って使用してください。
家族で1つのログインを使うと便利に感じますが、通知、ダッシュボード、デバイス追跡、監査の手がかり、保存されたセッション、アクセス無効化がすべて同じIDに結び付きます。まず個人用の標準アカウントを作成し、管理権限は分離してください。そして各ロールで実際に何を閲覧・変更できるかを確認します。壁掛けタブレットは、全員の代わりとなるものではなく、デバイス用のIDとして扱ってください。
個人、ユーザー、共有デバイスを分ける
インタラクティブなアクセスが必要な各世帯メンバー、各管理者、サービス連携、壁掛けタブレットなどの固定共有デバイスを一覧にします。そのIDに在席追跡、個人通知、設定へのアクセス、または共有ダッシュボードだけが必要かどうかを記録してください。
個人ごとのアカウントとダッシュボードを使用すると、個人のセッションを分離できます。ただし、ダッシュボードの選択を完全なセキュリティ分離と見なさず、実際の環境で現在の権限を確認してください。
個人には個人用アカウントを割り当て、管理者にも識別可能な個人用ログインを用意してください。自動アクセスが必要で、物理的な設置場所が管理されている場合は、固定ディスプレイに別の限定的なデバイスアカウントを使用できます。
説明責任、アクセス無効化、使い勝手を比較する
個人アカウントを使用すれば、1人のユーザーだけのセッションを削除でき、設定も分離され、アクティビティをより確実に解釈できます。共有ログインを1つだけ使う場合、パスワードの変更、デバイスの侵害、世帯からの離脱が全員に影響し、実際の操作主体を確実に区別できません。
世帯ごとの個別アカウントを選ぶと、初回設定の手間と引き換えに、個別のアクセス無効化と設定を利用できます。この判断は世帯の人数だけでなく、必要なロールに基づいて行ってください。
共有アクセスを選ぶのは、エンドポイントが共有用で、用途が限定され、個人のセッションを保持させるのが現実的でない場合に限ってください。利便性のために、そのアカウントを個人のスマートフォンで再利用したり、管理者権限を付与したりしないでください。
最小権限を適用し、実際の操作をテストする
世帯メンバーには標準アカウントを作成し、連携や設定を管理する人だけに管理者権限を与え、デフォルトダッシュボードを意図的に設定してください。各ロールから、通常の操作、履歴の閲覧範囲、設定へのアクセス、通知の振り分け、サインアウトの動作をテストします。
表示と認可の違いについては、世帯のIDモデルで詳しく説明しています。非表示のビューをアクセス制御の保証と誤解しそうな場合に活用してください。
標準ユーザーが世帯に必要な作業を実行できない場合は、サポートされている最小限のロール変更を行うか、その作業を見直してください。すべてのアカウントを管理者にしないでください。必要な単位で機密エンティティを分離できない場合は、それを製品上の制約として扱い、公開範囲を調整します。
デバイスの紛失と世帯の変更を確認する
テスト用アカウントからサインアウトし、そのセッションを無効化して、他の世帯アカウントが引き続き動作することを確認します。次に、共有デバイスや管理者の認証情報を変更せずに、スマートフォンを紛失した場合とユーザーが世帯を離れた場合をテストしてください。
共有ディスプレイでは再起動を行い、意図した限定ダッシュボードだけに戻ることを確認します。また、その認証情報が他の場所で再利用されていないことも確認してください。更新とアクセス無効化を担当する管理者を明確に決めておきます。
すべての個人と共有デバイスに明確なロール、必要最小限のアクセス、独立した削除経路が設定されるまで完了としないでください。現在の権限モデルで機密性の高い操作や履歴を保護できない場合は、上位の対応に移行してください。テストしたロールで実現できない分離を保証してはいけません。
世帯に変更があった後、および定期的なメンテナンス時にアカウント一覧を確認してください。使われていないデバイスセッションを削除し、現在の管理者を確認し、共有アカウントは作成時に想定した単一のエンドポイントだけに限定してください。
サポートとヒント
もっと読む

同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。

Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。

データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。

