Freigeben über

Übersicht - Schutz von Engineering-Systemen in SFI

Die Initiative Secure Future Initiative (SFI) wurde im November 2023 als mehrjähriger Versuch gestartet, die Art und Weise zu sichern, in der Microsoft seine Produkte und Dienste entwickelt, erstellt, testet und betreibt.

Das Design der SFI-Architektur konzentriert sich auf eine Reihe von Sicherheitsprinzipien, die in die Microsoft-Kultur und -Governance übernommen und integriert werden. Diese Sicherheitsgrundsätze werden auf eine Reihe fokussierter Engineering-Säulen durch Prozesse, Standards und kontinuierliche Verbesserungen angewendet.

In diesem Artikel wird die SFI-Säule "Schützen von Ingenieursystemen" zusammengefasst.

Bevor du anfängst

Säule und Ziele

Die Säule "Schützen von Engineering-Systemen" zielt darauf ab, die Sicherheit für Entwicklung und Engineering zu stärken, indem der Anlagenbestand effektiv verwaltet wird, Zero-Trust-Prinzipien implementiert werden, Pipelines gesichert werden sowie die Isolation und die Resilienz gestärkt werden.

Die Microsoft-Ziele und die Zero Trust/NIST-Zuordnung für diese Säule sind in der folgenden Tabelle zusammengefasst.

Säulenziel Zero Trust NIST-Zuordnung
1. Vollständiges Inventar der Softwareressource

Der Bestand umfasst alle Azure DevOps-Neupositionierungen und Pipelines mit vollständigen Metadaten. StartRight-Tooling stellt sicher, dass 80 % der Vermögenswerte bei der Erstellung inventarisiert werden und der Rest innerhalb von 24 Stunden erfasst wird. Dies ermöglicht eine schnelle Reaktion auf Vorfälle und universelle Richtlinienerzwingungen. Wir haben den Bestandsumfang mit feineren Eigentumsverhältnissen erhöht, um eine bessere Reaktion zu ermöglichen.		 Explizit überprüfen: Schützen von Identitätssignaturressourcen. Starker Nachweis von schlüsseln, die in den Workflow integriert sind. >
Gehen Sie von Sicherheitsverletzungen aus: Schützen Sie Schlüssel so, als ob eine Kompromittierung auftreten kann, indem Sie die hardwaregestützte Isolation verwenden.		 ID.AM-02 (Softwareplattformen und -anwendungen innerhalb der Organisation sind inventarisiert).
Die Aufrechterhaltung eines vollständigen Inventars aller Engineering-Softwareressourcen entspricht direkt der Anforderung von NIST, alle Software-/Plattformkomponenten nachzuverfolgen und zu steuern.
2. Zero Trust für den Quellcodezugriff

Reduzierter ständiger Zugriff für Administratorrollen und erforderliche Just-in-Time-Eskalation. Azure DevOps OAuth-basierte Apps nutzen die Microsoft Entra-Authentifizierung mit Durchsetzung von bedingtem Zugriff. Überprüfungen für Präsenznachweise decken fast alle Produktionscodeänderungen ab.		 Explizit überprüfen: Standardüberprüfungsbibliotheken reduzieren Die Variabilität und das Risiko. Verwenden Sie eine konsistente Überprüfung.

Gehen Sie von Sicherheitsverletzungen aus: Reduziert die Angriffsfläche von benutzerdefinierten Implementierungen.		 PR. AA-01 (Identitäten werden entsprechend dem Risiko authentifiziert).

PR. AA-02 (Access ist mit rollenbasierten Attributen autorisiert).
Starke Authentifizierung vor Codezugriff.

PR. AA-03 (Access wird mit Kontextattributen verwaltet).
Gerät, Standort und Sitzungsrisiko werden vor dem Repo-Zugriff überprüft.

PR. AA-04 (Access ist basierend auf Segmentierung und geringsten Berechtigungen eingeschränkt).
Erzwingung von Repository-, Verzweigungs- und Umgebungssegmentierung.

PR. AA-05 (Berechtigungen werden verwaltet, erzwungen und regelmäßig überprüft).
Kontinuierliche Überprüfung der Codezugriffsberechtigungen.

PR.AA-06 (Zugriff entspricht dem Prinzip der minimalen Berechtigung).
Zero Trust gewährleistet minimalen Zugriff auf Code-Repositorys.

PR.DS-01 (Daten werden in Übereinstimmung mit Unternehmensrichtlinien verwaltet).
Steuerelemente für die Behandlung vertraulicher Quellcodes.

PR.DS-02 (Daten werden beim Speichern geschützt).
Repo-Verschlüsselung und sichere Speicherung von Code.

PR.DS-10 (Der Zugriff auf Daten wird überwacht, um nicht autorisierte Aktivitäten zu erkennen).
Überwachen des Quellcodes für Anomalien.
3. Sichere Codeentwicklung

Der Codesignaturzugriff ist fast vollständig auf Produktionsidentitäten beschränkt. Repositories erzwingen Branch-Richtlinien mit einer Mindestanzahl an Genehmigern. Der Umfang dieses Ziels hat sich erhöht, um unsere Geheimerkennungsfunktionen zu optimieren. Wir haben eine analysegesteuerte Validierung eingeführt, um Compliance und Haltbarkeit zu stärken und uns zu positionieren, um systemische Risiken über engineering-workflows hinweg zu reduzieren.		 Explizit überprüfen: Sichere Authentifizierungstechniken überprüfen die Benutzeridentität bei jedem Zugriffsversuch.

Verwenden Sie die geringsten Berechtigungen: MFA stärkt die Erzwingung der geringsten Rechte, indem nicht autorisierter Zugriff reduziert wird.		 PR. AA-04 (Access ist mit Segmentierung und geringsten Berechtigungen eingeschränkt).
Das Design der Pipeline erzwingt Code-Verarbeitungsregeln.

PR.PS-06 (Dienste/Prozesse werden überprüft, um sicherheitsrelevante Anforderungen vor der Ausführung zu erfüllen).
Code muss vor der Bereitstellung Richtlinien + Pipeline-Sicherheitsüberprüfungen erfüllen.
4. Standardisieren sicherer Dev-Pipelines

Lieferkettenschutzlösungen entwickeln sich: Interne Artefakt-Feeds werden allgemein übernommen und die Komponentengovernance läuft standardmäßig. KI-Agents beheben jetzt Open-Source-Sicherheitsrisiken asynchron, wodurch die Latenz zwischen Erkennung und Auflösung reduziert wird. Diese Schritte bieten erhebliche Verbesserungen bei der Sicherheitslage und der betrieblichen Resilienz, um sicherzustellen, dass das Engineeringsystem hohe Standards in der gesamten Software-Lieferkette aufrecht erhält.		 Verwenden Sie die geringsten Berechtigungen: Einschränken des geheimen Zugriffs. Vermeiden Sie hartcodierte oder persistente Anmeldeinformationen.

Gehen Sie von Sicherheitsverletzungen aus: Behandeln Sie jedes Geheimnis als potenziell kompromittiert, es sei denn, es ist sicher geschützt.		 PR.DS-02 (Daten werden beim Speichern geschützt).
Sicherer Speicher für Buildartefakte und Geheimnisse.

PR.DS-10 (Der Zugriff auf Daten wird überwacht).
Überwachen von Pipelineartefakten und Protokollen

PR. IR-01 (Prozesse bereiten sich auf eine effektive Reaktion auf Vorfälle vor).
Pipelines umfassen Protokollierung, Alarmierung, Rollback, Herkunftsnachweis.

PR.PS-06 (Prozesse/Dienste werden vor der Ausführung auf Sicherheitsanforderungen überprüft).
Pipelines erzwingen obligatorische Sicherheitstore.
5. Schutz der Software-Lieferkette

Stellen Sie sicher, dass Identitätstoken durch Zustands- und Zeitüberprüfung geschützt sind.		 Explizit überprüfen: Vollüberprüfung von Identitätstoken an jedem Erzwingungspunkt.

Annehmen eines Verstoßes: Stellen Sie sicher, dass ungültige oder falsch formatierte Token abgelehnt werden.		 GV.SC-01 (Die Governance für Lieferkettenrisiken ist etabliert).

GV.SC-02 (Lieferanten und Abhängigkeiten werden identifiziert).

GV.SC-03 (Lieferanten werden auf Risiko bewertet).

GV.SC-04 (Sicherheitsanforderungen für Lieferanten werden festgelegt).

GV.SC-07 (Lieferkettenkomponenten werden auf Risiko überwacht).

GV.SC-09 (Lieferanten/Komponenten werden validiert, um den Anforderungen gerecht zu werden).

ID.RA-10 (Risiken von Lieferanten und Abhängigkeiten werden bewertet).

PR.PR-06 (Prozesse/Dienste werden überprüft, um Sicherheitsanforderungen vor der Ausführung zu erfüllen).

Nächste Schritte

  • Last updated on