De geheimen van het beoordelingsproces van Salesforce beveiliging
Beheerde 2GP's gemaakt vanuit TRIAL Dev Hubs zijn niet toegestaan
Beheerde 2GP's gemaakt vanuit TRIAL Dev Hubs kunnen niet worden beoordeeld door het security review team.
Zorg ervoor dat uw managed 2GP is aangemaakt met de Dev Hub in uw Partner Business Org (PBO).
Vergewis u er vervolgens van dat u een activering van uw PBO hebt aangevraagd, zodat deze van een TRIAL naar een ACTIVE status kan worden verplaatst.
U moet een case aanmelden en "Partner Community & AppExchange" selecteren voor het product en "Security Review" en vragen om de activering.
Scanresultaten van webtoepassingen opnemen voor domeinen van derden
Neem alle scanresultaten op van webtoepassingen voor domeinen van derden (niet-Salesforce) die zijn geïntegreerd in uw app.
Voeg alle niet-Salesforce endpoints toe in uw inzending, als samengestelde omgeving(en) en/of in de externe site-instellingen van uw Salesforce-test org. Voorbeeld https://testapi.net/
Niet-Salesforce domeinen/endpoints vallen binnen het bereik van de beveiligingsbeoordeling als ze op enigerlei wijze zijn geïntegreerd met uw Salesforce-component (bijv. als uw app er callouts naar maakt, als ze Salesforce-gegevens opslaan of als ze worden gebruikt voor andere doeleinden, zoals authenticatie).
Voorzie scanresultaten van een van de goedgekeurde scantools voor webtoepassingen voor alle sites die worden beoordeeld.
- Goedgekeurde scantools zijn onder andere OWASP ZAP, Chimera of Burp Suite.
- U moet alle problemen met een hoge ernstgraad die zijn gedetecteerd voor OWASP ZAP of Burp Suite corrigeren.
- Alle problemen gelabeld anders dan “Informational/Other” voor Chimera moeten ook worden gecorrigeerd.
- Bied schone scanresultaten of vul de resultaten aan met documentatie die vals-positieven verklaart.
- Als alternatief, als er geen problemen zijn gedetecteerd, geef dan een screenshot van het gescande eindpunt.
Verleen alle benodigde authenticatiegegevens, zoals gebruikersnaam/wachtwoorden of API-sleutels, die het Security Review Team nodig kan hebben om deze externe integraties te testen.
Iidentiteit uitdaging is ingeschakeld workaround
Identiteitsuitdaging is ingeschakeld op uw org. Als workaround moet u IP-bereiken van Salesforce safelisten.
U kunt een nieuwe org opzetten met de IP-adressen op de witte lijst en de multifactorauthenticatie (MFA) uitgeschakeld door de stappen te volgen in deze link.
Alternatief, volg de onderstaande stappen in uw huidige org:
- MFA uitschakelen met onderstaande stappen:
- Log in op de org en ga naar de setup sectie.
- Zoek naar “Session Settings” in de zoekbalk linksboven.
- Ga naar sessie-instellingen, dan “Session Security Levels”
- Selecteer Two-Factor Authentication van High Assurance en klik op remove.
- Druk op opslaan onderaan de pagina.
- Zet de Salesforce IP ranges en evenals de volgende ranges en adressen:
- 13.108.0.0 - 13.111.255.255
- 62.17.146.0 - 62.17.146.255
- 85.222.134.0 - 85.222.134.255
- 104.161.246.0 - 104.161.246.255
- 182.71.125.154 - 182.71.125.155
- 182.72.29.238 en 136.232.119.246
Delen in klassen afdwingen
Dwing delen af in uw klassen die salesforce standaard/aangepaste objecten openen/wijzigen.
Om deze kwetsbaarheid te omzeilen, moet u deze klassen "met delen" declareren.
Noot: Delen wordt al dan niet afgedwongen in de klasse die de DML-query's uitvoert. Als een klasse met delen een andere klasse "zonder delen" aanroept en de query's uitvoert, worden de objecten die worden opgehaald/gemodificeerd niet afgedwongen door delen.
Object (CRUD) en Field Level Security (FLS) worden geconfigureerd op profielen en rechtenreeksen en kunnen worden gebruikt om de toegang tot standaard en aangepaste objecten en individuele velden te beperken. Force.com-ontwikkelaars moeten hun applicaties zo ontwerpen dat de CRUD- en FLS-instellingen van de organisatie worden afgedwongen op zowel standaard- als aangepaste objecten en dat de toegang van een gebruiker geleidelijk wordt afgebroken.
Enkele gebruikssituaties waarbij het acceptabel zou kunnen zijn om CRUD/FLS te omzeilen zijn:
- Voor het maken van roll up overzichten of aggregaten die de gegevens niet direct tonen
- Het wijzigen van aangepaste objecten of velden zoals logs of systeemmetadata die niet direct toegankelijk zouden moeten zijn voor de gebruiker via CRUD/FLS
- Cases waar het verlenen van directe toegang tot het aangepaste object een minder veilig beveiligingsmodel creëert.
Zorg ervoor dat je deze use cases documenteert als onderdeel van je inzending.
Gevoelige informatie in Debug
Het onthullen van informatie in debug-verklaringen kan helpen bij het onthullen van potentiële aanvalsvectoren voor een aanvaller. Debugverklaringen kunnen van onschatbare waarde zijn voor het diagnosticeren van problemen in de functionaliteit van een applicatie, maar ze mogen niet publiekelijk gevoelige of te gedetailleerde informatie vrijgeven (dit omvat onder andere PII, wachtwoorden, sleutels en stack traces als foutmeldingen).
Geen gevoelige of PII gegevens mogen worden gelogd met de system.debug methode.
Gedeelde schending kwetsbaarheid
Het Force.com platform maakt uitgebreid gebruik van regels voor het delen van gegevens. Elk object kan unieke machtigingen hebben voor welke gebruikers en profielen kunnen lezen, maken, bewerken en verwijderen. Deze beperkingen worden afgedwongen bij gebruik van alle standaard controllers. Wanneer je een aangepaste Apex klasse gebruikt, worden de ingebouwde profielpermissies en beveiligingsbeperkingen op veldniveau niet gerespecteerd tijdens de uitvoering. Het standaard gedrag is dat een apex klasse de mogelijkheid heeft om alle gegevens met de organisatie te lezen en bij te werken. Omdat deze regels niet worden afgedwongen, moeten ontwikkelaars die Apex gebruiken ervoor zorgen dat ze niet onbedoeld gevoelige gegevens blootgeven die normaal verborgen zouden zijn voor gebruikers door profielgebaseerde machtigingen, beveiliging op veldniveau of organisatiebrede standaardwaarden. Dit geldt met name voor Visualforce-pagina's. Classes moeten waar mogelijk expliciet aangeven dat ze gedeeld mogen worden.
Verricht een uitgebreide evaluatie
Verricht een uitgebreide review van uw applicatie met het bovenstaande als richtlijn om vergelijkbare problemen te identificeren.
In de meeste gevallen, wanneer de beveiligingscontrole begint, zijn ze niet in staat om elk geval van elk type kwetsbaarheid te identificeren. Als gevolg daarvan zal hun rapport over het algemeen één voorbeeld van elk gevonden type kwetsbaarheid bevatten, en is het aan jou om te controleren op andere soortgelijke gevallen in je applicatie.
Bezoek de beveiligingsbronnen opnieuw.
Bezoek het Force.com Security Resources Center voor toegang tot gratis richtlijnen voor veilig coderen, tools en training.
Herhaal ZAP- en Checkmarx-rapporten. Naast handmatig testen kunt u deze geautomatiseerde testtools gebruiken:
Chimera
Web Application Scanner (ZAP)
Checkmarx - Security Code Scanner
Voordere bronnen:
Meer informatie hier Veiligheidsrichtlijnen voor Apex en Visualforce-ontwikkeling
Kijk voor meer diepgaand, interactief trainingsmateriaal naar de nieuwe trailhead voor ISV Security Review
U kunt op de hoogte blijven van waarschuwingen, deelnemen aan discussies en opmerkingen en vragen plaatsen in de Security Review Collaboration Group van de Partner Community.
Genereer een checklist voor indiening die is aangepast aan uw oplossing. Gebruik de Security Review Submission Requirements Checklist Builder.
Als u een pakketversie ter beoordeling hebt ingediend en deze is mislukt met feedback van het beveiligingsteam, zorg er dan voor dat u deze twee belangrijke punten in overweging neemt wanneer u klaar bent om een vervolgbeoordeling in te plannen.
- Als u code hebt gewijzigd die draait op het Salesforce-platform, moet u een nieuwe versie van uw beheerde pakket uploaden.
- Klik vanuit de Publishing Console op het tabblad 'Listings'.
- Klik op je vermelding.
- Link je nieuw geüploade beheerde pakketversie aan je vermelding door op de groene knop 'Selecteer pakket' te klikken.
- Ga naar het tabblad 'Packages' en klik op de link 'Start Review' naast het veld 'Security Review' op je nieuwste versie.
- Ga door de wizard voor beveiligingsbeoordelingen en volg het normale indieningsproces.
- Als u alleen code hebt gerepareerd die extern naar Salesforce wordt uitgevoerd, bewerkt u de bestaande informatie voor het indienen van beveiligingsbeoordelingen:
- Klik vanuit de Publishing Console op het tabblad 'Listings' als uw app geen Salesforce-pakket heeft (klik anders op het tabblad 'Packages').
- Klik op uw vermelding op het tabblad 'Listings' of, als u op het tabblad 'Packages' bent, scrol naar uw meest recent ingediende pakketversie.
- Klik op de link "Beoordeling bewerken" (in het tabblad 'APP' van de listing of naast de pakketversie in het tabblad 'Pakketten'). De link kan ook "Ingediend" zeggen in plaats van "Bewerk beoordeling".
- Ga door de wizard voor beveiligingsbeoordelingen en werk alle gewijzigde informatie bij.
- Het is verplicht om Log een case en selecteer "Partner Community & AppExchange" voor het Product en "Security Review" voor het Onderwerp om het Security Review Operations Team te laten weten dat je je product opnieuw ter beoordeling indient. Vermeld de naam, ID en versie van je pakket (of de link naar de aanbieding) in de beschrijving van de case.
Wij delen graag alle nuttige informatie en raden u aan meer te weten te komen over onze invloed op de releasecyclus in Salesforce
Pland een demo om meer te weten te komen over hoe Serpent uw Salesforce DevOps-strategie vandaag nog kan verbeteren! Serpent van Tekunda biedt een aantal uitstekende tools om uw DevOps-teams te helpen, waaronder ingebouwd versiebeheer, systemen voor continue implementatie en vrijgave, tools voor samenvoegen en tal van verschillende testtools.