LogoLogo
How to Build Dataspaces?Main IDSA AssetsOther ResourcesManifesto for International Data Spaces
IDS-RAM 4
IDS-RAM 4
  • README
  • Front Matter
    • Front Matter
    • Contributing Projects
  • Introduction
    • 1. Introduction
      • 1.1 Goals of the International Data Spaces
      • 1.2 Purpose and Structure of the Reference Architecture
      • 1.3 Relation to other IDSA assets
  • Context of the International Data Spaces
    • 2. Context of the International Data Spaces
      • 2.1 Data-Driven Business Ecosystems
      • 2.2 Data Sovereignty as a Key Capability
      • 2.3 Data as an Economic Good
      • 2.4 Data Exchange and Data Sharing
      • 2.5 Meaningful data
      • 2.6 Industrial Cloud Platforms
      • 2.7 Big Data and Artificial Intelligence
      • 2.8 The Internet of Things and the Industrial Internet of Things
      • 2.9 Blockchain
      • 2.10 Federated frameworks for data sharing agreements and terms of use
      • 2.11 General Data Protection Regulation
      • 2.12 Contribution of the International Data Spaces to Industry 4.0 and the Data Economy
      • 2.13 Privacy in the connected world
  • Layers of the Reference Architecture Model
    • 3 Layers of the Reference Architecture Model
      • 3.1 Business Layer
        • 3.1.1 Roles in the International Data Spaces
        • 3.1.2 Interaction of Roles
        • 3.1.3 Digital Identities
        • 3.1.4 Usage Contracts
      • 3.2 Functional Layer
      • 3.3 Information Layer
      • 3.4 Process Layer
        • 3.4.1 Onboarding
        • 3.4.2 Data Offering
        • 3.4.3 Contract Negotiation
        • 3.4.4 Exchanging Data
        • 3.4.5 Publishing and using Data Apps
        • 3.4.6 Policy Enforcement
      • 3.5 System Layer
        • 3.5.1 Identity Provider
        • 3.5.2 IDS Connector
        • 3.5.3 App Store and App Ecosystem
        • 3.5.4 Metadata Broker
        • 3.5.5 Clearing House
        • 3.5.6 Vocabulary Hub
  • Perspectives of the Reference Architecture Model
    • 4 Perspectives of the Reference Architecture Model
      • 4.1 Security Perspective
        • 4.1.1 Security Aspects addressed by the different Layers
        • 4.1.2 Identity and Trust Management
        • 4.1.3 Securing the Platform
        • 4.1.4 Securing Applications
        • 4.1.5 Securing Interactions between IDS components
        • 4.1.6 Usage Control
      • 4.2 Certification Perspective
        • 4.2.1 Certification Aspects Addressed by the Different Layers of the IDS-RAM
        • 4.2.2 Roles
        • 4.2.3 Operational Environment Certification
        • 4.2.4 Component Certification
        • 4.2.5 Processes
      • 4.3 Data Governance Perspective
        • 4.3.1 Governance Aspects Addressed by the Different Layers of the IDS-RAM
        • 4.3.2 Data Governance Model
        • 4.3.3 Data as an Economic Good
        • 4.3.4 Data Ownership
        • 4.3.5 Data Sovereignty
        • 4.3.6 Data Quality
        • 4.3.7 Data Provenance
        • 4.3.8 Data Space Instances
        • 4.3.9 IDS Rulebook
        • 4.3.10 Privacy Perspective
        • 4.3.11 Governance for Vocabularies
Powered by GitBook

Links:

  • IDSA Website
  • IDSA Github
  • Legal Notice
  • Privacy Policy

© 2016 – 2025 | All Rights Reserved | International Data Spaces Association

On this page
  • Security Measures in the Platform
  • Connector Core Services and Control Apps
  • Adapter and Data Apps
Edit on GitHub
  1. Perspectives of the Reference Architecture Model
  2. 4 Perspectives of the Reference Architecture Model
  3. 4.1 Security Perspective

4.1.4 Securing Applications

A secure platform is needed to guarantee the secure and isolated execution of all applications. This platform provides security mechanisms and enable applications to fulfill their security requirements. Building on a secure platform, all applications deployed on the connector need to integrate into the utilized security mechanisms and fulfill security requirements themselves.

Security Measures in the Platform

Security measures in the platform are responsible for ensuring a secure deployment of provided applications. The platform verifies authenticity and integrity of all applications by checking the signatures in the provided App Manifests before starting the applications. In case the IDS App is supplemented with usage control policies for licensing purposes (e.g., only allowing usage of the software for a certain amount of time or limiting the number of simultaneously running instances), the platform is responsible for enforcing those policies and only starting the application if the defined conditions are met.

Additionally, the platform enforces isolation, communication routes and privileges for all applications based on configuration from the Connector Core Services and/or Control Apps. While some configuration attributes may be set freely, security-critical configuration aspects (which were also assessed during certification) need to be:

  • set to fixed values embedded in the utilized software images (not allowing configuring through applications at runtime),

  • limited to a pre-defined set of options,

  • or validated by certified code (in the Connector Core Services or platform component) before coming into effect.

Connector Core Services and Control Apps

The Connector Core Services (or respective Core Services for other IDS components) and Control Apps are responsible for offering IDS-specific interfaces, configuring the entire connector stack securely and managing data exchange and processing on the connector. These applications often have higher privileges on the IDS Connector which are required to use and configure functionalities offered by runtime and kernel of the platform. The criteria for the certification of an IDS connector apply for these applications and need to be fulfilled by the combination of platform, Connector Core Services and (optionally) Control App. During certification, the applications must be evaluated as a part of the overall security concept for the connector software stack applications. They need to at least address/cover the following security requirements:

  • Authentication and authorization for external interfaces.

  • Ensuring integrity and confidentiality for all communication channels and sessions (see also Section 4.1.5).

  • Supporting negotiation and enforcement of usage control policies (see also Section 4.1.6).

  • Securely configuring the entire connector stack including the allowed communication routes between apps.

  • Logging relevant aspects, e.g., configuration changes, access control decisions, access to data resources.

  • For higher Trust Levels: Interacting with responsible kernel/runtime component for using key material protected by hardware mechanisms.

To reduce the attack surface, different functionalities should be split into modular and isolated applications interacting only via defined interfaces. The privileges for the applications should be reduced to those required for the respective functionality in accordance with the principle of least privilege.

Adapter and Data Apps

In contrast to Connector Core Services and Control Apps, Adapter and Data Apps are unprivileged and isolated containers which cannot modify the connector functionalities but rely on them to provide their app functionality. They need to fulfill specific app requirements, e.g. containing all necessary dependencies to form an independent container, conducting input validation for offered interfaces, and having a description matching the functionality provided by the application. However, they rely on the certified connector for securing communication channels to the outside world as well as authentication and authorization of users requesting access to provided interfaces.

Last updated 2 years ago