Säkerhetschecklista security-checklist

I det här avsnittet beskrivs olika åtgärder som du bör vidta för att se till att AEM är säker när du distribuerar. Checklistan ska användas uppifrån och ned.

Viktiga säkerhetsåtgärder main-security-measures

Kör AEM i produktionsklar läge run-aem-in-production-ready-mode

Mer information finns i Köra AEM i produktionsklart läge.

Aktivera HTTPS för transportlagersäkerhet enable-https-for-transport-layer-security

Det är obligatoriskt att aktivera HTTPS-transportlagret på både författare- och publiceringsinstanser för att en säker instans ska kunna användas.

Installera snabbkorrigeringar för säkerhet install-security-hotfixes

Kontrollera att du har installerat de senaste säkerhetsuppdateringarna från Adobe.

Ändra standardlösenord för AEM- och OSGi-konsolens administratörskonton change-default-passwords-for-the-aem-and-osgi-console-admin-accounts

Adobe rekommenderar att du efter installationen ändrar lösenordet för de behöriga AEM admin kontona (i alla instanser).

Dessa konton omfattar:

De här två kontona använder separata autentiseringsuppgifter och det är viktigt att ha tydliga, starka lösenord för var och en av dem för att driftsättningen ska vara säker.

Ändra AEM administratörslösenord changing-the-aem-admin-password

Lösenordet för AEM administratörskonto kan ändras via konsolen Bevilja åtgärder - användare.

Här kan du redigera admin-kontot och ändra lösenordet.

Viktigt att ändra lösenordet för OSGi-webbkonsolen importance-of-changing-the-osgi-web-console-password

Förutom AEM admin-kontot kan följande hända om du inte ändrar standardlösenordet för OSGi-webbkonsolen:

Mer information om hur du ändrar lösenord för webbkonsolen finns i Ändra administratörslösenordet för OSGi-webbkonsolen nedan.

Ändra administratörslösenordet för OSGi-webbkonsolen changing-the-osgi-web-console-admin-password

Ändra lösenordet som används för att komma åt webbkonsolen. Använd en OSGI-konfiguration för att uppdatera följande egenskaper för Apache Felix OSGi Management Console:

Så här ändrar du administratörslösenordet för OSGi-webbkonsolen:

Implementera anpassad felhanterare implement-custom-error-handler

Adobe rekommenderar att du definierar anpassade felhanterarsidor, särskilt för 404- och 500 HTTP Response-koder för att förhindra informationsexponering.

Fullständig checklista för Dispatcher complete-dispatcher-security-checklist

AEM Dispatcher är en viktig del av er infrastruktur. Adobe rekommenderar att du slutför Dispatcher checklista.

Verifieringssteg verification-steps

Konfigurera replikerings- och transportanvändare configure-replication-and-transport-users

En standardinstallation av AEM anger admin som användare för transportautentiseringsuppgifter inom replikeringsagenterna som standard. Administratörsanvändaren används också för att hämta replikeringen på författarsystemet.

Av säkerhetsskäl bör båda ändras för att återspegla det aktuella användningsfallet, med följande två aspekter i åtanke:

Kontrollera säkerhetshälsokontrollerna för instrumentpanelen för åtgärder check-the-operations-dashboard-security-health-checks

I AEM 6 introduceras den nya kontrollpanelen för åtgärder, som är avsedd att hjälpa systemansvariga att felsöka problem och övervaka en instans hälsa.

Kontrollpanelen innehåller också en samling säkerhetskontroller. Vi rekommenderar att du kontrollerar statusen för alla säkerhetshälsokontroller innan du publicerar med produktionsinstansen. Mer information finns i dokumentationen för Operations Dashboard.

Kontrollera om exempelinnehåll finns check-if-example-content-is-present

Allt exempelinnehåll och alla användare (till exempel Geometrixx och dess komponenter) ska avinstalleras och tas bort helt i ett produktionssystem innan det görs tillgängligt för allmänheten.

Se Arbeta med paket.

Kontrollera om CRX utvecklingspaket finns check-if-the-crx-development-bundles-are-present

Dessa OSGi-utvecklingspaket bör avinstalleras både på författaren och publicera produktionssystem innan de blir tillgängliga.

Kontrollera om Sling-utvecklingspaketet finns check-if-the-sling-development-bundle-is-present

AEM Developer Tools distribuerar installationsprogrammet för Apache Sling Tooling (org.apache.sling.tooling.support.install).

Detta OSGi-paket bör avinstalleras både på författaren och publicera produktionssystem innan de blir tillgängliga.

Protect mot smidning av förfrågningar på olika webbplatser protect-against-cross-site-request-forgery

CSRF Protection Framework the-csrf-protection-framework

AEM 6.1 levereras med en mekanism som hjälper till att skydda mot attacker med attacker med attacker med korsdomänsbegäran, vilket kallas CSRF Protection Framework. Mer information om hur du använder den finns i dokumentationen.

Sling Referer-filtret the-sling-referrer-filter

Om du vill åtgärda kända säkerhetsproblem med CSRF (Cross-Site Request Forgery) i CRX WebDAV och Apache Sling lägger du till konfigurationer så att referensfiltret kan använda det.

Refererarfiltertjänsten är en OSGi-tjänst som gör att du kan konfigurera följande:

Så här konfigurerar du referenspunktsfiltertjänsten:

OSGI-inställningar osgi-settings

Vissa OSGI-inställningar ställs in som standard för att underlätta felsökning av programmet. Ändra sådana inställningar för publiceringsinställningarna och författarens produktivitetsinstanser för att undvika att intern information läcker till allmänheten.

För var och en av följande tjänster måste de angivna inställningarna ändras:

Se OSGi-konfigurationsinställningar.

När du arbetar med AEM finns det flera metoder för att hantera konfigurationsinställningarna för sådana tjänster. Mer information och rekommenderade tillvägagångssätt finns i Konfigurera OSGi.

Ytterligare läsningar further-readings

Minska DoS-attacker (Denial of Service) mitigate-denial-of-service-dos-attacks

En denial of service-attack (DoS) är ett försök att göra en datorresurs otillgänglig för de avsedda användarna. Den här attacken utförs ofta genom att resursen överbelastas, till exempel:

Det finns många konfigurationspunkter för att förhindra sådana attacker, men endast de punkter som rör AEM diskuteras här.

Konfigurerar Sling för att förhindra DoS

Sling är innehållscentrerad. Bearbetningen är inriktad på innehållet eftersom varje (HTTP) begäran mappas till innehåll i form av en JCR-resurs (en databasnod):

Mer information finns i Bearbetning av delningsbegäran.

Sling är en kraftfull och flexibel metod, men som alltid är det den flexibilitet som måste hanteras noggrant.

För att förhindra missbruk kan du göra följande:

Korrigera mot DoS på grund av att formulärväljare används

Eftersom AEM inte tillhandahåller körklara index för FormChooserServlet kan formulärväljare i frågor utlösa en kostsam databasövergång, vilket vanligen gör att AEM instansen stannar. Formulärväljare kan identifieras med *.form.* sträng i frågor.

Du kan åtgärda det här problemet genom att göra följande:

Minskar mot DoS på grund av hämtningsservern

Med standardservern för hämtning av resurser kan autentiserade användare skicka godtyckligt stora, samtidiga hämtningsbegäranden för att skapa ZIP-filer med resurser. Om du skapar stora ZIP-arkiv kan servern och nätverket överbelastas. För att minska en potentiell denial of service-risk (DoS) som orsakas av detta beteende är AssetDownloadServlet OSGi-komponenten inaktiverad som standard på Experience Manager -publiceringsinstansen. Det är aktiverat på författarinstansen Experience Manager som standard.

Om du inte behöver nedladdningsfunktionen kan du inaktivera servern för författare och publicera distributioner. Om din installation kräver att funktionen för hämtning av resurser är aktiverad finns mer information i Hämta resurser från Adobe Experience Manager. Du kan också ange en maximal hämtningsgräns som din distribution kan stödja.

Inaktivera WebDAV disable-webdav

Inaktivera WebDAV både i skribent- och publiceringsmiljöer genom att stoppa rätt OSGi-paket.

Verifiera att du inte avslöjar personligt identifierbar information i användarens hemsökväg verify-that-you-are-not-disclosing-personally-identifiable-information-in-the-users-home-path

Det är viktigt att skydda dina användare genom att se till att du inte visar någon personligt identifierbar information i databasanvändarens hemsökväg.

Sedan AEM 6.1 har sättet som användar-ID-nodnamn (kallas även auktoriseringsbara) lagras på ändrats med en ny implementering av AuthorizableNodeName-gränssnittet. Det nya gränssnittet visar inte längre användar-ID:t i nodnamnet, utan genererar i stället ett slumpmässigt namn.

Ingen konfiguration måste utföras för att den ska kunna aktiveras eftersom det nu är standardsättet att generera auktoriserbara ID:n i AEM.

Även om det inte rekommenderas kan du inaktivera det om du behöver den gamla implementeringen för bakåtkompatibilitet med dina befintliga program. För att göra det måste du göra följande:

Anonymt behörighetskontrollpaket anonymous-permission-hardening-package

Som standard lagrar AEM systemmetadata, till exempel jcr:createdBy eller jcr:lastModifiedBy som nodegenskaper, bredvid det reguljära innehållet, i databasen. Beroende på konfigurationen och åtkomstkontrollkonfigurationen kan detta i vissa fall leda till exponering av personligt identifierbar information (PII), till exempel när sådana noder återges som rå JSON eller XML.

Precis som alla databasdata förmedlas dessa egenskaper av Oak behörighetsstack. Åtkomsten till dem bör begränsas i enlighet med principen om minst privilegium.

Som stöd för detta tillhandahåller Adobe ett behörighetskontrollerande paket som kan användas av kunder. Det fungerar genom att installera en "deny"-åtkomstkontrollpost i databasroten, vilket begränsar anonym åtkomst till vanliga systemegenskaper. Paketet kan hämtas och installeras på alla AEM som stöds.

För att illustrera ändringarna kan vi jämföra nodegenskaperna som kan visas anonymt innan paketet installeras:

med de som kan visas efter att paketet har installerats, där jcr:createdBy och jcr:lastModifiedBy inte är synliga:

Mer information finns i versionsinformationen för paketet.

Förhindra clickjacking prevent-clickjacking

För att förhindra clickjacking rekommenderar Adobe att du konfigurerar webbservern så att HTTP-huvudet X-FRAME-OPTIONS anges till SAMEORIGIN.

Mer information om clickjacking finns på OWASP-webbplatsen.

Se till att du replikerar krypteringsnycklar korrekt vid behov make-sure-you-properly-replicate-encryption-keys-when-needed

Vissa AEM funktioner och autentiseringsscheman kräver att du replikerar dina krypteringsnycklar i alla AEM instanser.

Innan du gör det utförs nyckelreplikering på olika sätt i olika versioner, eftersom det sätt som nycklarna lagras på skiljer sig åt mellan 6.3 och äldre versioner.

Mer information finns nedan.

Replikeringsnycklar för AEM 6.3 replicating-keys-for-aem

I äldre versioner lagrades replikeringsnycklarna i databasen, med början AEM 6.3 lagras de i filsystemet.

Om du vill replikera dina nycklar mellan instanser kopierar du dem från källinstansen till målinstansens plats i filsystemet.

Mer specifikt måste du göra följande:

Replikeringsnycklar för AEM 6.2 och äldre versioner replicating-keys-for-aem-and-older-versions

I AEM 6.2 och tidigare lagras nycklarna i databasen under noden /etc/key.

Det rekommenderade sättet att på ett säkert sätt replikera nycklarna mellan dina instanser är att bara replikera den här noden. Du kan selektivt replikera noder via CRXDE Lite:

Utför ett penetrationstest perform-a-penetration-test

Adobe rekommenderar att du utför ett penetrationstest av din AEM infrastruktur innan du börjar producera.

Bästa praxis för utveckling development-best-practices

Det är viktigt att den nya utvecklingen följer Bästa praxis för säkerhet för att säkerställa att AEM är säker.