役割によって分離された 2 つのプレーン
プラットフォームは、共通の階層化されたコアを共有する、独立してデプロイされる 2 つのサービスに分割されています。特権的なプロビジョニングをテナントごとのリクエストトラフィックから分離することで、それぞれの影響範囲を縮小します。規律ある階層化されたコア
両方のサービスは、一方向の依存関係ルールを持つ階層化アーキテクチャで Go で構築されています。個別に強制されるプラットフォーム層が製品レイヤーの下にあり、テナント分離と ID プリミティブを所有します。ファウンデーションは、テナントコンテキストを持たない共有インフラストラクチャユーティリティのために依存関係のない状態を維持します。1
プラットフォーム
テナント分離と ID の中核: データベースアクセス、セッション、テナントとリージョンの解決、アクター、ロギング、パブリック URL の処理。この層は個別にレビューおよび強制されるため、分離は通常の製品コードから切り離されます。
2
ファウンデーション
上位のものに依存しない共有インフラストラクチャユーティリティ (暗号化やトレースなど)。テナントスコープの関心事はここではなくプラットフォームにあります。
3
ドメイン
エンティティ (ユーザー、アプリケーション、ポリシーなど) ごとのビジネスロジック。プラットフォームとファウンデーションに依存し、ユースケースや REST には依存しません。
4
ユースケース
複雑なフローのために複数のドメインサービスを調整します。
5
REST
HTTP ハンドラーとミドルウェア。通信プロトコルを扱う唯一のレイヤーです。
この階層化は、コンパイラーによって保証される不変条件ではなく、文書化されたレビューで強制される規約です (リンティングとディレクトリ構造によって裏付けられています)。誇張せずに正直にそのことを明記しています。
ホスティングと強化
Iru Identity は、セキュリティが強化されたデプロイメントで AWS 上で実行されます。強化されたコンテナ
サービスは AWS Fargate 上で非 root として、読み取り専用のルートファイルシステム、no-new-privileges、およびすべての Linux ケーパビリティを削除した状態で実行されます。
常設のデータベースパスワードなし
アプリケーションは、短命の IAM 認証トークンを使用してマネージド PostgreSQL (Amazon RDS) に接続します。漏洩する静的な DB パスワードはありません。
シークレットはコードに含まれない
資格情報と署名キーは実行時にマネージドシークレットストアから挿入され、リポジトリにコミットされたり、データベースにプレーンテキストで保存されたりすることはありません。
スキャンされたサプライチェーン
コンテナイメージは、出荷前に CI パイプラインで脆弱性がスキャンされます。
2 つのリージョン、実際のデータレジデンシー
Iru Identity は 2 つの分離されたリージョン (米国us-east-2 と欧州連合 eu-central-1) で運用されており、レジデンシーは慣例ではなくコードで強制されます。
- すべてのテナントはリージョンに固定され、テナントレコードに保存されます。
- データベースレイヤーはリージョンごとに個別の接続プールを保持し、すべてのトランザクションをテナントのリージョンによってルーティングします。リージョンを解決できないリクエストは拒否されます。黙って別のリージョンにフォールバックすることはありません。
- リージョン固有のデータ操作 (シードデータなど) は、間違ったリージョンに対して実行できないよう制御されています。
稼働し続け、可観測性を備えるよう構築
ヘルスチェックとグレースフルシャットダウン
ヘルスチェックとグレースフルシャットダウン
依存関係のないライブネスエンドポイントにより、オーケストレーターはデータベースや認証に触れることなくプローブできます。シャットダウン時、サービスはトラフィックの受け入れを停止し、トレース、エラーレポート、データベース接続を順番にフラッシュします。
回復力のあるデータアクセス
回復力のあるデータアクセス
接続プールは調整および制限されており、起動時にデータベースに ping を送信し、到達できない場合は壊れたリクエストを処理するのではなくフェイルファストします。
結果整合性のあるプロビジョニング
結果整合性のあるプロビジョニング
アプリへのアカウントのプロビジョニングは、キャンセルを認識するバックグラウンドワーカーのアウトボックスと調整ループを通じて実行されるため、ダウンストリームの変更は失われることなく成功するまで再試行されます。
エンドツーエンドのトレース
エンドツーエンドのトレース
リクエストは OpenTelemetry で HTTP からアプリケーションコードを経て SQL クエリまでトレースされ、構造化ログはテナントとトレース ID によって相関付けられます。エラーは、忠実度とコストのバランスを取るためにサンプリングを使用して一元的に取得されます。
検証可能なマイグレーションと監査
検証可能なマイグレーションと監査
スキーマの変更は埋め込まれ、バージョン順に並べられ、チェックサムで検証されます (すでに適用されたマイグレーションが変更された場合はハードエラーになります)。常設のチェッカーが、すべてのテーブルの監査ジャーナルがライブスキーマと同期していることを証明します。
次のステップ
マルチテナント分離
行レベルセキュリティと追記専用の監査によって、すべてのテナントのデータを分離し、改ざん検知可能に保つ方法。
認証アーキテクチャ
フィッシング耐性のあるサインイン、署名付きリクエスト、および SSO の信頼の確立方法。
セキュリティとプライバシー
これらのメカニズムがもたらす保証。
システムアーキテクチャ
ID とサインインがどのように流れるかについての顧客向けの説明。