Dela via


Skydda meddelanden med transportsäkerhet

I det här avsnittet beskrivs msmq-transportsäkerhet (Message Queuing) som du kan använda för att skydda meddelanden som skickas till en kö.

Kommentar

Innan du läser igenom det här avsnittet rekommenderar vi att du läser Säkerhetsbegrepp.

Följande bild innehåller en konceptuell modell för köad kommunikation med hjälp av Windows Communication Foundation (WCF). Den här bilden och terminologin används för att förklara transportsäkerhetsbegrepp.

Queued Application Diagram

När du skickar köade meddelanden med WCF med NetMsmqBindingbifogas WCF-meddelandet som en brödtext i MSMQ-meddelandet. Transportsäkerhet skyddar hela MSMQ-meddelandet (MSMQ-meddelandehuvuden eller egenskaper och meddelandetexten). Eftersom det är brödtexten i MSMQ-meddelandet skyddar även WCF-meddelandet med transportsäkerhet.

Huvudkonceptet bakom transportsäkerhet är att klienten måste uppfylla säkerhetskraven för att få meddelandet till målkön. Detta skiljer sig från Meddelandesäkerhet, där meddelandet skyddas för det program som tar emot meddelandet.

Transportsäkerhet med hjälp av NetMsmqBinding och MsmqIntegrationBinding påverkar hur MSMQ-meddelanden skyddas under överföring mellan överföringskön och målkön där skyddade innebär:

  • Signera meddelandet för att säkerställa att det inte har manipulerats.

  • Kryptera meddelandet för att säkerställa att det inte kan ses eller manipuleras. Detta rekommenderas men är valfritt.

  • Målköhanteraren som identifierar avsändaren av meddelandet för icke-avvisande.

I MSMQ, oberoende av autentisering, har målkön en åtkomstkontrollista (ACL) för att kontrollera om klienten har behörighet att skicka meddelandet till målkön. Det mottagande programmet kontrolleras också för behörighet att ta emot meddelandet från målkön.

Säkerhetsegenskaper för WCF MSMQ-transport

MSMQ använder Windows-säkerhet för autentisering. Den använder Windows säkerhetsidentifierare (SID) för att identifiera klienten och använder Active Directory-katalogtjänsten som certifikatutfärdare när klienten autentiseras. Detta kräver att MSMQ installeras med Active Directory-integrering. Eftersom Windows-domänens SID används för att identifiera klienten är det här säkerhetsalternativet bara meningsfullt när både klienten och tjänsten ingår i samma Windows-domän.

MSMQ ger också möjlighet att bifoga ett certifikat med meddelandet som inte är registrerat med Active Directory. I det här fallet säkerställer det att meddelandet signerades med det bifogade certifikatet.

WCF tillhandahåller båda dessa alternativ som en del av MSMQ-transportsäkerheten och de är den viktigaste pivoten för transportsäkerhet.

Som standard är transportsäkerheten aktiverad.

Med tanke på dessa grunder beskriver följande avsnitt transportsäkerhetsegenskaper som paketeras med NetMsmqBinding och MsmqIntegrationBinding.

MSMQ-autentiseringsläge

Avgör MsmqAuthenticationMode om du vill använda Windows-domänsäkerheten eller en extern certifikatbaserad säkerhet för att skydda meddelandet. I båda autentiseringslägena använder den WCF-köade transportkanalen den CertificateValidationMode som anges i tjänstkonfigurationen. Certifikatverifieringsläget anger den mekanism som används för att kontrollera certifikatets giltighet.

När transportsäkerhet är aktiverat är WindowsDomainstandardinställningen .

Autentiseringsläge för Windows-domän

Valet att använda Windows-säkerhet kräver Active Directory-integrering. WindowsDomain är standardläget för transportsäkerhet. När detta anges ansluter WCF-kanalen Windows SID till MSMQ-meddelandet och använder sitt interna certifikat som hämtats från Active Directory. MSMQ använder det här interna certifikatet för att skydda meddelandet. Den mottagande köhanteraren använder Active Directory för att söka efter och hitta ett matchande certifikat för att autentisera klienten och kontrollerar att SID också matchar klientens. Det här autentiseringssteget körs om ett certifikat, antingen internt genererat vid WindowsDomain autentiseringsläge eller externt genererat i Certificate autentiseringsläge, är kopplat till meddelandet även om målkön inte har markerats som kräver autentisering.

Kommentar

När du skapar en kö kan du markera kön som en autentiserad kö för att indikera att kön kräver autentisering av klienten som skickar meddelanden till kön. Detta säkerställer att inga oautentiserade meddelanden accepteras i kön.

DET SID som är kopplat till meddelandet används också för att kontrollera mot målköns ACL för att säkerställa att klienten har behörighet att skicka meddelanden till kön.

Certifikatautentiseringsläge

Valet av att använda certifikatautentiseringsläge kräver inte Active Directory-integrering. I vissa fall, till exempel när MSMQ är installerat i arbetsgruppsläge (utan Active Directory-integrering) eller när du använder överföringsprotokollet SOAP Reliable Messaging Protocol (SRMP) för att skicka meddelanden till kön, fungerar bara Certificate .

När du skickar ett WCF-meddelande med Certificateansluter WCF-kanalen inte ett Windows SID till MSMQ-meddelandet. Därför måste målköns ACL tillåta Anonymous användaråtkomst att skicka till kön. Den mottagande köhanteraren kontrollerar om MSMQ-meddelandet har signerats med certifikatet men inte utför någon autentisering.

Certifikatet med dess anspråk och identitetsinformation fylls i i ServiceSecurityContext av den WCF-köade transportkanalen. Tjänsten kan använda den här informationen för att utföra sin egen autentisering av avsändaren.

MSMQ-skyddsnivå

Skyddsnivån avgör hur MSMQ-meddelandet ska skyddas för att säkerställa att det inte manipuleras. Den anges i egenskapen MsmqProtectionLevel . Standardvärdet är Sign.

Teckenskyddsnivå

MSMQ-meddelandet signeras med det internt genererade certifikatet när du använder WindowsDomain autentiseringsläge eller ett externt genererat certifikat när du använder Certificate autentiseringsläge.

Tecken- och krypteringsskyddsnivå

MSMQ-meddelandet signeras med det internt genererade certifikatet när du använder WindowsDomain autentiseringsläge eller externt genererat certifikat när du använder Certificate autentiseringsläge.

Förutom att signera meddelandet krypteras MSMQ-meddelandet med hjälp av den offentliga nyckeln för certifikatet som hämtats från Active Directory som tillhör den mottagande köhanteraren som är värd för målkön. Den sändande köhanteraren ser till att MSMQ-meddelandet krypteras under överföring. Den mottagande köhanteraren dekrypterar MSMQ-meddelandet med hjälp av den privata nyckeln för det interna certifikatet och lagrar meddelandet i kön (om det autentiseras och auktoriseras) i klartext.

Kommentar

För att kryptera meddelandet krävs Active Directory-åtkomst (UseActiveDirectory egenskapen NetMsmqBinding måste vara inställd på true) och kan användas med både Certificate och WindowsDomain.

Ingen skyddsnivå

Detta är underförstått när MsmqProtectionLevel är inställt på None. Detta kan inte vara ett giltigt värde för andra autentiseringslägen.

Kommentar

Om MSMQ-meddelandet är signerat kontrollerar MSMQ om meddelandet är signerat med det bifogade certifikatet (internt eller externt) oberoende av köns tillstånd, det vill säga autentiserad kö eller inte.

MSMQ-krypteringsalgoritm

Krypteringsalgoritmen anger vilken algoritm som ska användas för att kryptera MSMQ-meddelandet på tråden. Den här egenskapen används endast om MsmqProtectionLevel är inställd på EncryptAndSign.

Algoritmerna som stöds är RC4Stream och AES och standardvärdet är RC4Stream.

Du kan bara använda algoritmen AES om avsändaren har MSMQ 4.0 installerat. Dessutom måste målkön också finnas på MSMQ 4.0.

MSMQ Hash-algoritm

Hash-algoritmen anger den algoritm som används för att skapa en digital signatur för MSMQ-meddelandet. Den mottagande köhanteraren använder samma algoritm för att autentisera MSMQ-meddelandet. Den här egenskapen används endast om MsmqProtectionLevel är inställd på Sign eller EncryptAndSign.

De algoritmer som stöds är MD5, SHA1, SHA256och SHA512. Standardvärdet är SHA1.

På grund av kollisionsproblem med MD5/SHA1 rekommenderar Microsoft SHA256 eller bättre.

Se även