MXC politika örnekleri

Bu örneklerde iş yükü gereksinimlerinin MXC kaynak izinlerine nasıl çevrildiği gösterilmektedir. C#, TypeScript veya Rust hızlı başlangıcıyla başlayıp yapılandırmayı iş yükünüz için uyarlayabilirsiniz.

Aşağıdaki JSON, MXC şeması için ham 1.0.0 şeklini kullanır. Tam yapılandırmalar bir sürüm ve komut içerir; parçalar olarak etiketlenmiş bölümlerin mevcut bir yapılandırmaya dahil edilmesi gerekir. C#, TypeScript veya Rust'ta yazarken, belirli bir şema sürümü gerektirmeyen ilgili V1 SDK türlerini kullanın.

Bunlar Windows örneklerdir. Dosya yollarını ana makinenizdeki mevcut kaynaklarla değiştirin, ek araç bağımlılıklarını kasıtlı olarak verin ve SDK sürümünüzün ve arka ucunuzun seçili denetimleri desteklediğini onaylayın.

Depo düzeyinde bir araç çalıştırın

Bu tam yapılandırma, hızlı başlangıç ile aynı okuma-girdisi/yazma-çıktısı desenini kullanır. Çalıştırmadan önce C:\src\mxc-output ve C:\src\my-app\input.txt dizinini oluşturun. Komut kaynak dizinini okuyabilir ve çıkış dizinine yazabilir, ancak kaynak dizinine yazamaz ya da ağı veya kullanıcı arabirimini kullanamaz.

{
  "$schema": "https://raw.githubusercontent.com/microsoft/mxc/main/schemas/stable/mxc-config.schema.1.0.0.json",
  "version": "1.0.0",
  "containment": "process",
  "process": {
    "commandLine": "C:\\Windows\\System32\\cmd.exe /d /c type input.txt > C:\\src\\mxc-output\\result.txt",
    "cwd": "C:\\src\\my-app",
    "env": [
      "SystemRoot=C:\\Windows",
      "LOCALAPPDATA=C:\\src\\mxc-output",
      "TEMP=C:\\src\\mxc-output",
      "TMP=C:\\src\\mxc-output"
    ],
    "timeout": 30000
  },
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app", "C:\\Windows\\System32\\cmd.exe"],
    "readwritePaths": ["C:\\src\\mxc-output"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "injection": false
  }
}

Bu örnekte, Windows’un C:\Windows konumuna yüklü olduğu varsayılır; ana bilgisayarınızda gerçek sistem dizinini kullanın. Açık env listeye sahip bir Windows ProcessContainer isteği hem LOCALAPPDATA hem de SystemRoot içermelidir. Komutu bir derleme veya analiz aracıyla değiştirdiğinizde, deponun tamamına yazma erişimi vermek yerine önbelleklerini ve geçici dosyalarını ayrılmış yazılabilir dizini kullanacak şekilde yapılandırın.

Daha geniş bir yetkilendirme içinde kimlik bilgilerini koruma

Önceki yapılandırma, C:\src\my-app için okuma erişimi verir. Bu dizin bir ortam dosyası veya gizli dizini içeriyorsa, salt okunur ve okuma-yazma listelerini koruyarak bu parçayı mevcut filesystem bölümüne ekleyin:

{
  "deniedPaths": [
    "C:\\src\\my-app\\.env",
    "C:\\src\\my-app\\secrets"
  ]
}

Bu reddedilen yollar izin verilen kaynak dizinin içindedir. İlişkisiz depoları ve kullanıcı profili dizinlerini yetki kapsamının dışında tutun.

Mümkün olduğunda gizli bilgileri izin verilen ağaçların dışında tutun. Seçili arka uçta çakışan izinleri ve retleri doğrulayın; bazı mount edilmiş dizin arka uçları, bunları uygulamak yerine iç içe yerleştirilmiş retleri reddeder.

IP aralığına doğrudan erişime izin ver

Bu yapılandırma parçası network bölümünün yerini alır. Onaylı bir CIDR aralığına 443 numaralı giden TCP trafiğine izin verir ve diğer çıkış, giriş ve konak geri döngü erişimini reddeder. İş yükünden kabul etmek yerine, onaylanmış aralıkları güvenilir yapılandırmadan sağlayın.

{
  "network": {
    "egress": {
      "default": "deny",
      "allow": [
        {
          "to": [{ "cidr": "192.0.2.0/24" }],
          "ports": [{ "protocol": "tcp", "port": 443 }]
        }
      ]
    },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  }
}

192.0.2.0/24 yalnızca belgelendirme amaçlı bir aralıktır. Bunu istenen hizmetin onaylı adresleriyle değiştirin. Kural, bu bağlantı noktasında TCP'ye izin verir; yalnızca HTTPS'ye, tek bir konak adına veya tek bir uygulama hizmetine değil. Doğrudan ana bilgisayar adı çözümlemesi ayrı bir DNS kuralı gerektirebilir.

Bu örnek, doğrudan çıkış kurallarını destekleyen bir arka uç ve konak gerektirir. Bunu runtimeConfig.networkProxy ile birleştirmeyin. Ana bilgisayar adı tabanlı HTTP(S) kararları için bunun yerine desteklenen bir proxy tabanlı yapılandırma kullanın.

Uygulama tarafından sağlanan ara sunucuyu kullan

Konak uygulamanızın iş yükünü başlatmadan önce proxy'sini başlatması gerekir. Bu örnek MXC'yi var olan bir ara sunucuyu kullanacak şekilde yapılandırıyor; proxy'nin istek işleme ilkesini uygulamaz, başlatmaz veya onaylamaz.

Aşağıdaki yapılandırma parçası, desteklenen, işletim sistemi kapsamlı bir ara sunucu zorunlu kılma yoluyla Windows ProcessContainer’ı hedefler. Komutu, dosya sistemi izinlerini, zaman aşımını ve kullanıcı arabirimi kısıtlamalarını koruyarak bunu tam yapılandırmayla birleştirin. Uç noktayı ve karşı taraf adını çalışan proxy'nizinkilerle değiştirin.

{
  "containment": "processcontainer",
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "allow", "hostLoopback": "deny" }
  },
  "runtimeConfig": {
    "networkProxy": "http://127.0.0.1:8080"
  },
  "processContainer": {
    "network": {
      "allowedProxyPeer": "<package-family-name-or-appcontainer-profile-name>"
    }
  }
}

allowedProxyPeer, proxy'nin yüklü paketini veya paketlenmemiş AppContainer profilini tanımlar. Vekil sunucu, yapılandırılan geri döngü adresini ve bağlantı noktasını dinlemeli ve belgelenmiş Windows önkoşullarını karşılamalıdır. MXC bu kimliği URL'den çıkarmıyor.

Important

Bu Windows eşlemesi, özel ağ sunucu trafiğine de izin veren ingress.default: "allow" gerektirir. hostLoopback: "deny" yapılandırılan ara sunucu eşlerine erişilebilir durumdayken genel konak geri döngü erişimini kapalı tutar. Örnek, tüm gelen trafiğin reddedildiği bir yapılandırma değildir.

Doğrudan İnternet erişimi uygulama yolunda reddedilmeye devam eder. Proxy, hangi HTTP(S) isteklerini ileteceğini denetler. AppContainer kimliği olmayan düz, paketlenmemiş bir ana bilgisayar proxy'si farklı, daha geniş bir uyumluluk yapılandırmasına ihtiyaç duyar; allowedProxyPeer kaldırmayın ve aynı kısıtlamaların geçerli olduğunu varsaymayın.

Karşılık gelen SDK türlerini kullanın ve yalnızca ara sunucu erişimine güvenmeden önce desteği doğrulayın. Windows önkoşulları için ProcessContainer proxy dağıtım seçenekleri ve diğer arka uçlar için yönlü ağ iletişimi bölümüne bakın.

Geniş kullanıcı arabirimi erişimi olmadan görünür bir araca izin verme

Görünür bir pencere ve pano girişi gerektiren bir iş yükü için, bu yapılandırma parçası, ui öğesinin yerini alır. Windows ve pano okumalarına izin verir, ancak pano yazmalarına veya yapay klavye ve işaretçi girişlerine izin vermez:

{
  "ui": {
    "disable": false,
    "clipboard": "read",
    "injection": false
  }
}

V1 SDK'sındaContainerRequest, eşdeğer kullanıcı arabirimi özellikleri clipboard, allowInputInjection ve disable şeklindedir. Pano okumalarına yalnızca iş yükü gerektirdiğinde izin verin. Çalışma zamanı kullanıcı arabirimi desteğini denetleyin ve her hedef konakta gerekli kısıtlamaları test edin.

Durum bilgisi olan bir korumalı alanı yeniden kullanma

Komutların bir ortamı paylaşması gerektiğinde durum bilgisi olan yürütmeyi kullanın. Kaynağı oluşturun ve başlatın, komutları yürütün, ardından işiniz bittiğinde durdurun ve kaynağı kaldırın. Yalnızca başarıdan sonra değil, hata ve iptal sonrasında temizlemeyi düzenleyin.

Durum bilgisi olan çağrılar, yukarıdaki tek seferlik yapılandırmanın tamamını değil, aşamaya özgü ProvisionRequest ve her komut için ayrı bir ExecutionRequest kullanır. Sağlama, bir opak ContainerIddöndürür; onu değiştirmeden sonraki aşamalara iletin. V1 yaşam döngüsü API'lerinin desteklediği arka uçlar olan IsolationSession veya WSLc ile .NET'te provisionContainer, TypeScript yaşam döngüsü işlevlerini (örneğin provision_container) ya da Rust'ta v1::container işlevlerini (örneğin MxcLifecycle) kullanın. Tam gereksinimler için yaşam döngüsü kavramları, MXC kapsayıcı yaşam döngüsü ve .NET, TypeScript veya Rust SDK kılavuzuna bakın.

Her yaşam döngüsü arka ucu seçmeden önce neleri zorunlu kıldığını denetleyin. IsolationSession, iş yükünün kullanıcısını ve oturumunu ayırır, ancak MXC dosya sistemi, kullanıcı arabirimi veya ağ filtrelemesi uygulamaz ve isteğinde tüm ağ trafiğine açıkça izin verilmelidir. WSLc ağı, hedef başına kurallar olmadan tamamen yalıtılmış veya tamamen köprülüdür. Ayrıntılar için bkz. Kapsama türü seçme ve Arka uç seçimi ve ayarları.

Örnekleri doğrulayın

Uyarlanan her ilke için hem hedeflenen davranışı hem de kötüye kullanım girişimini test edin:

  • Gerekli girişlerin okunabildiğini ve gerekli çıkışların yazılabildiğini onaylayın.
  • Kimlik bilgilerinin ve ilişkisiz dosyaların erişilemez durumda kaldığını onaylayın.
  • Doğrudan, yerel ağ, geri döngü ve gelen bağlantıların ilkeyle eşleşip eşleşmediğini onaylayın.
  • Ara sunucu tabanlı erişim için, onaylanmış bir isteğin başarılı olduğunu ve doğrudan İnternet denemesinin başarısız olduğunu doğrulayın.
  • Pano, girdi enjeksiyonu ve görünür pencerelerin kullanıcı arabirimi ilkesiyle eşleşip eşleşmediğini onaylayın.
  • Başarılı, başarısız ve iptalden sonra zaman aşımlarının ve temizlemenin çalıştığını onaylayın.

Eksik erişimi araştırmak için Öğrenme Modu'nu kullanın. Bir temsilci çalıştırmasının gözlemlediği her kaynağa otomatik olarak izin vermeyin.

İlgili içerik

  • Son güncelleştirme: