En utilisant AWS re:Post, vous acceptez les AWS re:Post Conditions d’utilisation
AWS re:Postre:Post

Why does api-gw-cache-enabled-and-encrypted require caching for NIST 800-171 compliance?

0

The AWS Config Operational Best Practices for NIST 800 171 includes a config rule api-gw-cache-enabled-and-encrypted which requires all methods to have caching enabled and encrypted. I understand why the check would want to ensure that any cache is encrypted in the spirit of NIST 800-171, but I don't see why caching should be required for every method. Does anyone know why the rule was written the way it is?

Sujets
Sécurité, identité et conformitéSans serveurWeb et mobile front-endRéseaux et diffusion de contenu
Balises
Sécurité, identité et conformitéPasserelle API AmazonMise en cache
Langue
English
emattheis
demandé il y a 2 ans357 vues
1 réponse
0

You are correct in your understanding that api-gw-cache-enabled-and-encrypted rule requires that all methods in Amazon API Gateway stages have caching enabled and encrypted.

Please note that Amazon API Gateway throttles requests to your API to prevent it from being overwhelmed by too many requests. Caching reduces the number of calls made to your endpoint and also improve the latency of requests to your API.

In general, a Config rule is included in the conformance pack to maintain security best practices within an architecture. NIST complaince too, provides the set of standards for recommended security controls for information systems at federal agencies.

Secondly, the rules are classified into a standard after considering common industry use cases. That is why, this particular rule is included into NIST conformance pack.

AWS
INGÉNIEUR EN ASSISTANCE TECHNIQUE
AWS-User-4405679
répondu il y a 2 ans
  • emattheis
    il y a 2 ans

    So, I think the real question is about whether it is a security best practice to enable caching on every method. I would argue that it is not. In all but the most trivial use cases, adding a cache to a method increases the security risk because you have to consider how to secure and segregate the cache. Obviously the config enforces the use of encryption to protect the cached data at rest, but If you don't construct the cache key appropriately you might expose information to an unauthorized party. Of course, in many cases a cache makes no sense at all, e.g. a request that initiatives a unique task and returns a unique response.

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions

Contenus pertinents