ITインフラ基盤構築 設計書シリーズ:DX時代の基本的な設計、その全体像とは【会員限定】

基本設計書

DX時代の基本的な設計、その全体像とは

はじめに:DX時代の基本的な設計、その重要性

ITインフラ基盤の構築は、まるで広大な海を航海するようなもの。目的地が明確でなければ、座礁したり、見当違いの場所にたどり着いてしまったりしますよね。そんな時、私たちエンジニアが頼りにするのが「基本設計書」です。これは、単なる書類ではありません。目指すDX基盤の全体像を明確にし、プロジェクトを成功へと導くための青写真なのです。

今回の記事では、この基本設計書に焦点を当て、その役割や重要性、そして具体的なDX基盤を例にしながら、その奥深さを解説していきます。読者の皆さんには、基本設計書がなぜ、どのようにして、IT導入や活用において不可欠な存在なのか、その理解を深めていただければ幸いです。HITOSHIの個人的な感想としては、基本設計書はプロジェクトの「おへそ」のようなもので、ここがしっかりしていないと、後々あちこちでトラブルが起きがちなんですよね。

設計成果物の詳細:DX基盤を例に見る基本設計書の中身

それでは、具体的なDX基盤を例に、基本設計書にどのような項目が記載されるべきかを見ていきましょう。基本設計書は、システム開発の設計プロセスにおいて、要件定義で洗い出された機能や非機能要件をどのように実現するかを具体的に記述する重要なドキュメントです。システムの全体像と主要な構成要素を明確にするための設計図のような役割を果たします。

一般的な基本設計書には、以下の主要項目が含まれます。

  • システム概要:
    システムの目的、対象利用者、提供する価値などを記述します。
  • 機能要件:
    システムが持つべき具体的な機能(例:ログイン、データ登録、検索など)を一覧化します。
  • 非機能要件:
    性能、可用性、セキュリティ、保守性、拡張性など、機能以外の要件を記述します。
  • システム構成図:
    システムを構成するサーバー、ネットワーク機器、ミドルウェアなどの物理的・論理的な配置を図で示します。
  • データモデル:
    システムで扱うデータの構造や関係性を定義します。
  • インターフェース設計:
    他システムとの連携方法や、ユーザーインターフェースの基本的な設計を記述します。
  • セキュリティ設計:
    認証、認可、データ暗号化など、セキュリティに関する設計方針を記述します。

これらの項目は、後続の詳細設計や開発工程における具体的な作業の基盤となります。

1. IDP(Identity Provider)基盤設計:認証・認可の一元化とセキュアなアクセスを実現する

IDP基盤は、社員のアクセス管理やシングルサインオン(SSO)を実現し、利便性とセキュリティを両立させるための要となります。この設計では、ユーザーの「誰であるか(認証)」と「何ができるか(認可)」を明確にすることが重要です。

機能要件と非機能要件

IDP基盤は、ユーザー認証の一元化、SSOによる利便性向上、そしてセキュリティ強化を目的とします。具体的な機能要件としては、以下が挙げられます。

  • ユーザー認証機能:
    パスワード認証はもちろん、多要素認証(MFA)への対応も必須です。
    MFAの種類(TOTP、FIDO2など)や、認証ポリシー(パスワードの複雑性、有効期限など)を詳細に定義します。
    また、生体認証やデバイス証明書との連携も視野に入れることで、より堅牢な認証フローを設計します。
  • シングルサインオン(SSO)機能:
    SAML、OpenID Connectといった標準プロトコルへの対応範囲を明確にし、連携対象となるアプリケーションとの具体的な連携方式(IdP-initiated SSO、SP-initiated SSOなど)を記述します。
    これにより、ユーザーは一度の認証で複数のサービスを利用できるようになります。
  • ユーザー情報管理機能:
    アカウントの作成、更新、削除のワークフロー、属性情報(氏名、メールアドレス、所属部署、役職など)の管理項目を定義します。
    属性ベースのアクセス制御(ABAC)を見据えた設計も検討します。
  • ID連携機能:
    Active Directoryや人事システムなど、既存のIDソースとの連携方法(同期、フェデレーションなど)を記述します。
    これにより、ID管理の自動化と一元化を図ります。

非機能要件においては、特にセキュリティと性能が重要です。

  • セキュリティ:
    パスワードポリシーの厳格化、ブルートフォースアタック対策、不正アクセス検知、ログ監視体制を詳細に定義します。
    認証プロトコルにおける署名・暗号化の利用も明記し、認証情報の漏洩リスクを最小限に抑えます。
  • 性能:
    同時接続ユーザー数に対する認証応答時間(例:10,000ユーザー同時ログイン時に3秒以内)や、ユーザー情報検索の応答速度などを具体的に設定します。
    ピーク時のトラフィックにも耐えうる設計が不可欠です。
  • 可用性:
    システム停止許容時間(例:年間99.99%の稼働率)、DR(災害復旧)対策として、複数リージョンでの冗長化やバックアップ・リカバリ戦略を記述します。
    これにより、認証基盤がダウンすることによる業務停止リスクを回避します。
  • 拡張性:
    将来的なユーザー数増加(例:5年後には現在の2倍)や、連携アプリケーションの追加に対応できるようなシステム構成を考慮します。
    クラウドサービスを利用する場合、オートスケーリング機能の活用も検討します。

システム構成図とセキュリティ設計の具体例

システム構成図

  • 配置
    • ID管理サーバー(例:Active Directory、LDAPサーバーなど)、
    • SSO用IDPサーバー(例:Okta, Azure AD, Auth0など)
  • ネットワーク構成
    • DMZ
    • 内部ネットワーク
    • ファイアウォール設定
    • ロードバランサー配置

上記を図で示します。

特に、インターネットからのアクセス経路と、内部システムへのアクセス経路におけるセキュリティゾーンの分離を明確にします。

セキュリティ設計では、認証プロトコル(SAML 2.0, OpenID Connect)のバージョンと利用方法、多要素認証 (MFA) の具体的な導入方式(例:スマートフォンアプリ連携、生体認証など)、そして最小権限の原則(Principle of Least Privilege: PoLP)に基づいたロールベースのアクセス制御 (RBAC) における役割と権限のマッピングを詳細に記述します。特に、管理者権限の分離と、定期的な権限レビューのプロセスも盛り込むべきです。

2. 社員管理基盤(超極秘システム基盤)設計:最高レベルのセキュリティで機密情報を守る

社員のプライバシー情報、マイナンバー、その他社員管理に必要な超機密情報を保管するこのシステムは、何よりもセキュリティを最優先した設計が求められます。単なるデータ管理システムではなく、法規制遵守と強固な防御策を兼ね備えた「要塞」を構築する意識が必要です。

機能要件と非機能要件

本基盤の目的は、社員の個人情報を一元的に安全に保管・管理し、関連業務の効率化を図ることです。

  • 社員情報登録・更新・削除機能:
    氏名、住所、連絡先などの基本情報に加え、緊急連絡先、扶養家族情報、学歴、職歴、評価履歴、給与情報といった機密性の高い情報を管理する項目定義を行います。
    これらの情報は厳密なアクセス制限のもとで扱われるべきです。
  • マイナンバー管理機能:
    マイナンバーの登録、参照、利用履歴管理に関する機能要件を厳格に定義します。
    特に、マイナンバー法に準拠した管理方法(収集制限、利用制限、提供制限、保管制限、廃棄制限)を設計に盛り込み、各プロセスのトレーサビリティを確保します。
  • 給与・人事評価情報管理機能:
    給与明細、賞与、人事考課、目標設定といった超機密情報の入力、参照、更新機能を定義します。
    これらの情報には、特に厳重なアクセス制限と監査が必要です。
  • アクセスログ管理機能:
    誰が、いつ、どの情報に、どのような操作を行ったかを詳細に記録するログ機能を定義し、監査要件を満たすことを明記します。
    ログの改ざんを防ぐため、WORM(Write Once Read Many)方式のストレージ利用や、SIEM(Security Information and Event Management)連携によるリアルタイム監視と分析を検討します。
  • データ暗号化・復号化機能:
    データベースに保存されるデータ、ファイルサーバーに保存される添付ファイルなど、全ての機密情報が暗号化されることを明記し、暗号化方式(例:AES-256)と鍵管理方法を定義します。
    Transparent Data Encryption (TDE) の採用を検討する際、利用するデータベース(Oracle, SQL Server, PostgreSQLなど)における実装方式の違いを考慮し、選択したベンダー製品での具体的な適用方法を記述します。

非機能要件においては、セキュリティが本基盤の「命」であり、最高レベルの対策が必要です。

  • セキュリティ:
    • データ暗号化:
      保存データ(Data at Rest)と通信データ(Data in Transit)の双方に対する暗号化方式(例:AES-256)と、鍵管理システム(KMS: Key Management Service)の導入を記述します。
      特にKMSは、暗号鍵の生成、保管、管理、破棄を一元的に行うための重要な仕組みです。
    • アクセス制御:
      多要素認証の強制、IPアドレス制限、そしてゼロトラスト原則に基づいた職務分離(Separation of Duties)を徹底した厳格なロールベースアクセス制御(RBAC)を設計します。
      管理者権限の分離や、アクセス可能な時間帯の制限、さらには異常検知時の自動ブロック機能なども考慮すべきです。
    • 監査ログ:
      全てのアクセスおよび操作履歴を詳細に記録し、改ざん防止機能を持たせることを明記します。
      ログの長期保管と定期的な監査プロセスも定義し、不正の早期発見に努めます。
    • 脆弱性管理:
      定期的な脆弱性スキャン、ペネトレーションテストの実施計画を盛り込み、発見された脆弱性への対処プロセスを定義します。
      CI/CDパイプラインにセキュリティテストを組み込むDevSecOpsの考え方も導入します。
    • 物理的セキュリティ:
      サーバー室への入退室管理、監視カメラ、生体認証など、物理的なセキュリティ対策も基本設計に含めます。
      これは、どんなにサイバーセキュリティ対策を講じても、物理的な侵入を許してしまえば意味がないためです。
  • 可用性:
    システムの冗長化構成(例:アクティブ-スタンバイ、アクティブ-アクティブ)、バックアップ・リカバリ戦略(RPO: Recovery Point Objective, RTO: Recovery Time Objective を具体的に設定)を記述します。
    定期的なバックアップデータのリストアテストも計画に含めます。
  • 信頼性:
    データの整合性を保証するためのトランザクション管理、データのバックアップとリストア、定期的なデータ整合性チェックの仕組みを定義します。
  • 法規制遵守:
    個人情報保護法、マイナンバー法、そしてGDPR(General Data Protection Regulation)(該当する場合)など、関連する全ての法規制に厳格に準拠するための設計方針を詳細に記述します。
    特にGDPRにおいては、データ主体の権利(アクセス権、訂正権、削除権、データポータビリティ権など)への対応方法を明記します。

システム構成図とセキュリティ設計の具体例

システム構成図では、物理的に隔離されたサーバー、または専用のクラウドVPC(Virtual Private Cloud)の使用を明記します。

データベースは暗号化機能付きのDB(例:Transparent Data Encryption)、監査機能付きDBを選定します。

ネットワークは閉域網の利用を基本とし、厳格なファイアウォール設定、IDS/IPS(不正侵入検知/防御システム)の導入を図示します。

HSM(Hardware Security Module)のような専用セキュリティモジュールの利用も検討し、図に盛り込みます。

セキュリティ設計においては、データ暗号化の詳細、アクセス制御の詳細(どのユーザーがどのデータに、どのような操作を許可されるか)、監査ログの設計(記録項目、保存期間、分析方法)、脆弱性管理のプロセス、そして物理セキュリティ対策を包括的に記述します。

3. SASE(Secure Access Service Edge)基盤設計:ゼロトラスト時代に適合するネットワークとセキュリティの融合

SASE基盤は、分散するユーザーやデバイスからのセキュアなアクセスと、クラウドアプリケーションへの安全な接続を実現します。これは、従来の境界型セキュリティモデルの限界に対応し、ネットワークとセキュリティ機能をクラウドで統合する、次世代のセキュリティアプローチです。

機能要件と非機能要件

SASE基盤は、ネットワークとセキュリティ機能をクラウドで統合し、どこからでも安全かつ最適化されたアクセスを提供することを目指します。

  • セキュアWebゲートウェイ (SWG) 機能:
    URLフィルタリング、マルウェア対策、サンドボックス機能、DLP(Data Loss Prevention)など、Webアクセスにおけるセキュリティ機能を定義します。
  • CASB (Cloud Access Security Broker) 機能:
    クラウドアプリケーション(SaaS)へのアクセス制御、機密情報がクラウド上でどのように利用されているかの可視化、シャドーITの検出機能を定義します。
  • ZTNA (Zero Trust Network Access) 機能:
    ユーザーやデバイスがどこにいても、個々のアクセス要求に対して常に認証・認可を行うゼロトラストアプローチに基づくアクセス制御を記述します。
    VPNとの関係性については、「VPNを補完し、特定のアクセスシナリオにおいては代替する」という形で記述することで、現状の技術的な位置づけを正確に表現します。
    BYOD(Bring Your Own Device)デバイスからの安全なアクセスもZTNAの範疇で考慮します。
  • ファイアウォール機能(FWaaS):
    クラウドベースのファイアウォール機能で、トラフィックの検査とポリシー適用を行います。
  • SD-WAN (Software-Defined Wide Area Network) 機能:
    ブランチオフィスやリモート拠点からのネットワークトラフィックを最適化し、SASEクラウドへの効率的なルーティングを定義します。
    これにより、広域ネットワークの管理を効率化し、パフォーマンスを向上させます。
  • 統合ログ・レポート機能:
    全てのセキュリティイベント、アクセストランザクション、ネットワークトラフィックのログを一元的に収集・管理し、分析・レポートが可能な機能を定義します。
    生成AIを活用したログ分析や、予兆検知の仕組みも検討対象となります。

非機能要件では、SASE基盤のグローバルな展開と性能、そしてセキュリティが特に重要です。

  • 性能:
    世界各地のPoP(Point of Presence)からのアクセスにおける低遅延性、ピーク時における十分な帯域幅の確保を定義します。
    動画会議や大容量データ転送など、具体的な利用シーンを想定した要件設定が必要です。
  • 可用性:
    サービス稼働率のSLA(Service Level Agreement)を明確にし、ベンダーの冗長化構成やDR対策を確認します。
  • セキュリティ:
    新しい脅威への迅速な対応能力、データ損失防止(DLP)の精度、継続的な脆弱性診断の有無を確認します。
    IDベーストラフィック制御など、より詳細な制御も可能か検討します。
  • 管理性:
    統一された管理コンソールでのポリシー管理、ユーザー・デバイス管理の容易さを評価します。

システム構成図とセキュリティ設計の具体例

システム構成図では、選択するSASEベンダーのクラウドサービス(例:Zscaler, Palo Alto Networks Prisma Access, Fortinet FortiSASEなど)を中心に、社内ネットワークやブランチオフィス、リモートユーザーからの接続方法(VPN、専用線、クライアントソフトウェア、Webブラウザ経由)を図で示します。

ユーザーがどこからでもSASEクラウドのPoPに接続し、そこからアプリケーションへアクセスする流れを明確にします。

セキュリティ設計では、ゼロトラストアプローチに基づくアクセス制御ポリシーの詳細、URLフィルタリングのカテゴリとアクション、マルウェア対策エンジンの設定、サンドボックス機能の挙動、CASBにおけるSaaSアプリへの可視化と制御方法、DLPポリシーの定義(個人情報、機密情報の検出ルールとアクション)を具体的に記述します。

4. 業務フロー基盤(稟議や承認が必要な業務のコミュニケーションと進捗管理基盤)設計:業務の透明化と効率化を促進する

社内の稟議や承認プロセスを電子化し、効率化するための基盤である業務フロー基盤は、使いやすさと柔軟性だけでなく、業務の監査証跡やガバナンス対応も視野に入れた設計が求められます。

機能要件と非機能要件

本基盤は、稟議書や申請書の作成・提出から、承認フローの電子化、進捗状況の可視化、関連するコミュニケーションの促進を目的とします。

  • フォーム作成・管理機能:
    HTMLフォーム、PDFフォーム、Excelファイルなど、様々な形式の申請フォームを柔軟に作成・編集・管理できる機能を定義します。
    入力規則や必須項目設定、条件分岐によるフォーム項目の動的な表示/非表示も含まれます。
  • ワークフロー設定・管理機能:
    承認ルートの分岐、並列承認、条件分岐(例:金額に応じて承認者が変わる)、差し戻し、スキップといった複雑なフローに対応できる柔軟な設定機能を記述します。
    代理承認機能や承認期限設定、エスカレーション設定も考慮します。
  • 申請・承認機能:
    申請者が簡単に申請書を提出でき、承認者が迅速に承認・却下・差し戻し操作を行えるUI/UXを設計します。
    モバイルデバイスからの操作性も重視します。
  • コメント・メッセージ機能:
    申請者と承認者、関係者間でのコミュニケーションを円滑にするため、申請書に対するコメント機能やメッセージ機能を定義します。
    スレッド形式でのやり取りやファイル添付機能も考慮します。
  • 進捗状況可視化機能:
    各申請書の現在のステータス、承認者の情報、履歴などを一覧で確認できるダッシュボード機能や検索機能を設計します。
    これにより、業務のボトルネックを特定しやすくなります。
  • 文書管理・検索機能:
    承認された申請書を電子文書として保管し、キーワードや属性で検索できる機能を定義します。
    監査証跡(誰がいつ、何を承認したか、全てのプロセス履歴)が確実に記録・保持されるように設計します。
  • 通知機能:
    申請の提出、承認、差し戻し、期限切れが近づいた際などに、メールやチャットツール(例:Slack, Microsoft Teams)と連携して自動通知を行う機能を定義します。

非機能要件では、業務フロー基盤の利用者の利便性とシステムの安定性が重要です。

  • 操作性:
    直感的で使いやすいUI/UXを最優先し、ユーザーが迷わずに操作できることを目指します。
    ノーコード/ローコードでのフォーム作成機能なども検討し、現場部門での活用を促進します。
  • 拡張性:
    新しい業務フローや申請フォームの追加、組織変更に伴う承認ルートの変更に、システム側で柔軟に対応できるような設計を考慮します。
    API連携による外部システムとの連携も容易にします。
  • 可用性:
    システムの安定稼働を保証するための冗長化構成や、定期的なバックアップ・リカバリ計画を記述します。
  • 連携性:
    会計システム(例:SAP, Oracle EBS)、人事システム(例:Workday)、グループウェア(例:Microsoft 365, Google Workspace)など、他の社内システムとのデータ連携方法(API連携、ファイル連携など)を定義します。
    ガバナンス対応として、SOX法など特定の法規制に準拠したデータ連携と監査体制も設計に盛り込みます。

システム構成図とデータモデルの具体例

システム構成図では、ワークフローエンジン(BPMN対応の有無など)、Webアプリケーションサーバー、データベース(申請データ、承認履歴、マスターデータなどを格納)、外部連携のためのメールサーバーやチャットツール連携APIを図で示します。

データモデルでは、申請ID、申請者、承認者、申請日時、承認状況、承認日時、添付ファイルといった申請書に関する情報に加え、ワークフロー定義データ、組織情報、ユーザー情報などのエンティティとそれらのリレーションシップをER図などで詳細に表現します。特に、全ての承認履歴や差し戻し履歴が時系列で追跡できるようなデータ構造を設計します。

5. その他の一般的な会社で必要なDX基盤の基本設計書

上記以外にも、DXを推進する上で一般的な会社で必要となる基盤は多岐にわたります。それぞれの基本設計書も同様に、システム概要、機能要件、非機能要件、システム構成図、データモデル、インターフェース設計、セキュリティ設計などを具体的に記述します。

  • データ基盤:
    • データウェアハウス (DWH) / データレイク:
      異なる業務システムからデータを集約し、分析に活用するための基盤です。
      基本設計書では、データの収集方法(ETL/ELT)、保管形式、データマートの設計、データガバナンスポリシーなどを定義します。
    • BI (Business Intelligence) ツール:
      DWH/データレイクのデータを可視化し、意思決定を支援するツールの導入に関する設計です。
      レポートの種類、ダッシュボードの設計、ユーザーインターフェース、データ更新頻度などを記述します。
  • コミュニケーション&コラボレーション基盤:
    • グループウェア:
      スケジュール管理、会議室予約、情報共有(掲示板、ファイル共有)など、日常業務を円滑にするための機能設計を行います。
    • ビジネスチャット:
      社内コミュニケーションの効率化を目的とした機能設計(グループチャット、メンション、ファイル共有、絵文字など)と、既存システムとの連携を記述します。
    • Web会議システム:
      リモートワークを支えるための機能(画面共有、録画、ブレイクアウトルームなど)や、音質・画質に関する非機能要件を定義します。
  • 開発・運用基盤:
    • CI/CD (継続的インテグレーション/継続的デリバリー) ツール:
      開発からテスト、デプロイまでの一連のプロセスを自動化するための環境設計です。
      パイプラインの構成、利用ツール(例:Jenkins, GitLab CI/CD)、コードリポジトリとの連携などを記述します。
    • 監視・ログ管理システム:
      システムの稼働状況やパフォーマンスを常時監視し、障害発生時の迅速な検知・対応を可能にするための設計です。
      監視対象項目、閾値設定、アラート通知、ログ収集・分析方法を定義します。
    • IaC (Infrastructure as Code) ツール:
      インフラ構築をコードで管理し、自動化・再現性を高めるための設計です。
      利用ツール(例:Terraform, Ansible)、コードのバージョン管理、デプロイフローなどを記述します。
  • セキュリティ基盤(SASEとは別に):
    • EDR (Endpoint Detection and Response):
      エンドポイントにおける脅威を検知・対処するための設計です。
      エンドポイントへのエージェント導入、検知ルール、隔離・修復フローを定義します。
    • SIEM (Security Information and Event Management):
      セキュリティログを一元管理・分析し、脅威を特定するための設計です。
      ログソース、相関分析ルール、アラート生成、ダッシュボード設計を記述します。
    • WAF (Web Application Firewall):
      Webアプリケーションへの攻撃(SQLインジェクション、XSSなど)から保護するための設計です。
      保護対象、検出ルール、ブロックアクション、ログ管理を定義します。

まとめ:基本設計書が紡ぐ、DXの未来

今回の記事では、ITインフラ基盤構築における基本設計書の重要性について、DX基盤を例に挙げながら解説してきました。基本設計書は、単なる技術文書ではなく、DXを推進するための強力なツールであり、プロジェクト関係者全員が同じ方向を向いて進むための道標です。

クライアントとベンダー、双方の視点から基本設計のポイントを押さえ、質の高い設計書を作成することで、手戻りを減らし、システム開発の成功確率を高めることができます。そして、システムは構築されて終わりではなく、運用と継続的な改善を通じて、その価値を最大化していくものです。

この「ITインフラ基盤構築 設計書シリーズ」が、皆さんのDX推進の一助となれば幸いです。ITの世界は日進月歩ですが、基本的な設計思想やドキュメンテーションの重要性は変わりません。HITOSHIからの個人的なメッセージとしては、どんなに新しい技術が出てきても、基本を疎かにしないことが、長い目で見て一番の近道だと強く感じています。たまには立ち止まって、設計の「おへそ」を見直してみるのも良いかもしれませんね。

ITインフラ基盤構築 設計書シリーズ:DX時代の基本的な設計、その全体像とは【会員限定】

【巻末付録】基本設計書テンプレート構成例

以下に、今回の記事で触れた内容をベースにした、基本設計書のテンプレート構成例を提示します。これはあくまで一例であり、プロジェクトの規模や特性に応じて適宜調整してください。

1. システム概要

  • 1.1. システムの目的と背景
  • 1.2. 対象範囲(スコープ)
  • 1.3. 利用者と期待される効果
  • 1.4. システム全体像(概念図)

2. 機能要件

  • 2.1. 主要機能一覧
  • 2.2. 各機能の詳細(ユースケース、画面遷移、入力/出力項目など)
    • 2.2.1. (例)ユーザー認証機能
    • 2.2.2. (例)社員情報管理機能

3. 非機能要件

  • 3.1. 性能要件(処理性能、応答時間、スループット、拡張性など)
  • 3.2. 可用性要件(稼働率、RTO/RPO、冗長化、障害復旧手順など)
  • 3.3. セキュリティ要件(認証、認可、暗号化、監査、脆弱性対策など)
  • 3.4. 運用・保守要件(監視、バックアップ、ログ管理、パッチ適用など)
  • 3.5. 移行要件(データ移行方式、旧システムとの連携など)
  • 3.6. 環境要件(OS、ミドルウェア、開発言語、クラウド環境など)
  • 3.7. 法規制・コンプライアンス要件(個人情報保護法、マイナンバー法、GDPRなど)

4. システム構成設計

  • 4.1. 物理構成図
  • 4.2. 論理構成図
  • 4.3. ネットワーク構成図
  • 4.4. サーバー/サービス構成(VM/コンテナ、クラウドサービスなど)
  • 4.5. ミドルウェア構成

5. データモデル設計

  • 5.1. エンティティ関連図(ER図)
  • 5.2. 主要エンティティ定義(項目名、データ型、制約など)
  • 5.3. データフロー図

6. インターフェース設計

  • 6.1. 外部システム連携インターフェース(API仕様、ファイル連携仕様など)
  • 6.2. ユーザーインターフェース(画面レイアウトの基本方針、操作性ガイドラインなど)

7. セキュリティ設計

  • 7.1. 認証・認可設計(多要素認証、SSO連携、RBACなど)
  • 7.2. データ保護設計(データ暗号化、鍵管理、DLPなど)
  • 7.3. ネットワークセキュリティ設計(FW、IDS/IPS、SASE機能など)
  • 7.4. ログ・監査設計(監査ログ項目、改ざん防止、SIEM連携など)
  • 7.5. 脆弱性管理方針(脆弱性診断、ペネトレーションテスト計画)
  • 7.6. 物理的セキュリティ対策

8. 運用設計(基本方針)

  • 8.1. 監視・アラート方針
  • 8.2. バックアップ・リカバリ方針
  • 8.3. インシデント管理方針
  • 8.4. 変更管理方針

9. 品質保証・テスト方針

  • 9.1. テスト計画(単体、結合、総合テストの方針)
  • 9.2. 品質目標(バグ密度、リリース基準など)

10. 添付資料

  • 要件定義書、各種調査資料、参考情報など

ITインフラ基盤構築 設計書シリーズ

ショップ リンク – SHOP LINK –

COCO-SHOP QR
COCO-SHOP QR
JUICY-SHOP QR
JUICY-SHOP QR
UTme-QR
UTme-QR

お問い合わせ・ご相談窓口

ITインフラ、Web活用、セキュリティのことでお悩みなら、ぜひご相談ください。貴社の課題に合わせ、最適な解決策をご提案します。

ランサーズ / クラウドワークスからのご依頼も受付中

Lancers
Crowd Works
メールアドレス
お問合せ内容をご記入ください。

株式会社 十志 / JUICY LTD.をもっと見る

購読すると最新の投稿がメールで送信されます。


コメント

コメントを残す

JUICY LTD.をもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む