Sanket.Chat
Beveiliging: controle door de klant

Controle door de klant: uw infrastructuur, uw sleutels, uw regels

SANKET (Sanket.Chat) van Tosh Defence geeft de klant volledige zeggenschap over alles rond de eigen communicatie: de eigen infrastructuur, sleutels, identiteitsprovider, beleidsregels, het moment van updates, de huisstijl, bewaartermijnen en de uitrolarchitectuur, van een cloud naar keuze tot een volledig van andere netwerken geïsoleerd netwerk. Die mate van zeggenschap is het onderscheidende voordeel van SANKET: gehoste berichtendiensten zijn eenvoudigweg niet ontworpen om die te bieden.

Versleuteling bepaalt wie een bericht kan lezen. Zeggenschap bepaalt de rest: wie de dienst beheert, wie toegang krijgt, welke apparaten worden vertrouwd, wanneer de software verandert en waar de registraties worden opgeslagen. Met SANKET vallen al die beslissingen binnen uw eigen beveiligingsgrens.

Uw infrastructuur en uw sleutels

Elke installatie van Sanket is voor één organisatie bestemd en draait waar die organisatie beslist: in een cloudaccount in een regio naar keuze, op infrastructuur van Tosh Defence, in het eigen datacentrum of in een gesloten netwerk. Er is geen door de leverancier beheerde dienst betrokken bij de verzending van berichten.

De privésleutels van gebruikers worden op hun apparaten gegenereerd en beschermd door opslag met hardwarematige beveiliging. Servergeheimen blijven binnen de installatie, in sleutelopslag waaruit ze niet kunnen worden geëxporteerd. Alleen de openbare sleutels voor licentie- en releaseverificatie zijn afkomstig van Tosh Defence.

Uw identiteitsprovider en uw beheerders

De organisatie bepaalt hoe identiteiten worden aangemaakt: door beheerders, via uitnodigingen voor eenmalig gebruik (de standaard) of via SCIM 2.0 vanuit haar eigen directory. Registratie kan worden getoetst aan LDAP of Active Directory, en beheerders kunnen zich aanmelden via de eigen OpenID Connect- of SAML 2.0-provider van de organisatie. Openbare identiteitsproviders worden geweigerd en er wordt nooit een account aangemaakt enkel omdat iemand zich heeft aangemeld.

Beheerders verifiëren zich met FIDO2-beveiligingssleutels en werken binnen rollen met afgebakende rechten. Elke beheerhandeling wordt vastgelegd in een met SHA-256 gehashte, aaneengeschakelde auditlog.

  • FIDO2-beveiligingssleutels voor beheerders
  • Eenmalige aanmelding via uw eigen identiteitsprovider
  • Automatisering van instroom, functiewijzigingen en uitstroom met SCIM 2.0
  • Beheerdersrollen met afgebakende rechten

Uw apparaten

Het beheer van apparaten ligt bij de organisatie. Elk apparaat wordt goedgekeurd voordat het iets ontvangt, heeft sleutels die door hardware worden beschermd, staat op de ondertekende apparaatlijst van zijn account en presenteert via wederzijdse TLS-authenticatie voor apparaten een eigen clientcertificaat dat onder de certificaatautoriteit van de klant is uitgegeven. Beheerders kunnen een apparaat op elk moment in de verloren-modus zetten, de goedkeuring intrekken of het op afstand wissen.

Uw beleid, bewaartermijnen en huisstijl

Beveiliging, berichten, bestanden, gesprekken, groepen, bewaartermijnen, meldingen en integraties worden geregeld door de beleidsregels van de afzonderlijke installatie, die de organisatie vaststelt. Classificatielabels worden door de klant gedefinieerd, met maximaal acht gerangschikte labels. Gebruiksanalyses van de aanbieder zelf blijven binnen de installatie en kunnen voor de hele installatie worden uitgeschakeld of permanent worden geblokkeerd.

Installaties van Sanket.Work dragen de eigen naam en huisstijl van de organisatie, zodat gebruikers die te zien krijgen.

U bepaalt wanneer updates worden uitgevoerd, met ondertekende releases

Releases zijn ondertekende pakketten met een softwarestuklijst. De installatie controleert vóór het laden de handtekening en elke hash, weigert een verlopen release (bescherming tegen bevriezing van updates) en weigert elke release die ouder is dan de geregistreerde release (bescherming tegen terugdraaien). De wijzigingsbevoegde van de organisatie bepaalt wanneer de installatie plaatsvindt; bij een upgrade wordt de systeemstatus gecontroleerd en bij een fout wordt automatisch teruggedraaid. Upgrades via een netwerkverbinding zijn optioneel en het starten van een upgrade via de beheerconsole is standaard uitgeschakeld.

Technische onderbouwing

Lees de details in de whitepaper van SANKET

Elke bewering op deze pagina wordt volledig uiteengezet in het openbare technische witboek over de beveiliging en architectuur van Sanket, dat zonder registratie gratis te lezen is.

Veelgestelde vragen

Veelgestelde vragen

Stel ons team een vraag

Wat betekent zeggenschap van de klant bij Sanket?

De klant is eigenaar van en beslist over zijn infrastructuur, sleutels, identiteitsprovider, beleidsregels, het moment van bijwerken, merkidentiteit, bewaartermijnen en implementatiearchitectuur. Elke installatie is bestemd voor één organisatie, van een gekozen cloud tot een volledig van andere netwerken geïsoleerde omgeving.

Wie beheert de versleutelingssleutels?

De privésleutels van gebruikers worden op hun eigen apparaten gegenereerd en opgeslagen in door hardware beveiligde opslag. Servergeheimen blijven binnen de installatie van de klant. Tosh Defence bezit geen sleutels van klanten.

Kunnen we onze eigen identiteitsprovider gebruiken?

Ja. Gebruikers kunnen via SCIM 2.0 worden aangemaakt en worden gecontroleerd via LDAP of Active Directory. Beheerders kunnen zich via uw eigen OpenID Connect- of SAML 2.0-provider aanmelden in combinatie met een FIDO2-beveiligingssleutel.

Wie beslist wanneer SANKET wordt bijgewerkt?

Dat doet u. Digitaal ondertekende versies worden alleen geïnstalleerd na goedkeuring door uw wijzigingsbeheer. Verlopen en oudere versies worden geweigerd en een mislukte upgrade wordt automatisch teruggedraaid.

Kan Sanket de huisstijl van onze organisatie krijgen?

Ja. Sanket.Work-installaties kunnen de eigen naam en huisstijl van de organisatie dragen, zodat gebruikers die te zien krijgen.

Kunnen we onze eigen bewaartermijnen instellen?

Ja. De beheerders van de organisatie stellen de bewaartermijnen in voor berichten, berichten aan meerdere ontvangers, gesprekslogboeken, waarschuwingen en verdwijnende berichten.

Wat is wederzijdse TLS-authenticatie tussen apparaten?

Elk goedgekeurd apparaat heeft een eigen clientcertificaat. Dit wordt gegenereerd op basis van een sleutel die op het apparaat is aangemaakt, uitgegeven onder de certificeringsinstantie van de klant en bij elke verbinding aangeboden als onafhankelijk bewijs van de identiteit van het apparaat.

Neem de controle over de communicatie van uw organisatie

Tosh Defence helpt u een installatie te ontwerpen die aansluit op uw infrastructuur, identiteitsprovider, beleid en releaseproces.