как гарантировать вызывающему абоненту aws lambda, что предоставленные данные останутся в безопасности

Этот вопрос имеет некоторое сходство с отключить переменные среды AWS Lambda по своей общей цели, но направлен в первую очередь на доступ к сети.

Я хотел бы предоставить третьей стороне возможность вызывать мою функцию Lambda. Третья сторона отправит свои собственные данные в функцию Lambda (либо через полезную нагрузку, либо указав местоположение данных, например, ведро S3).

Я бы хотел, чтобы служба Lambda могла гарантировать третьей стороне, что предоставленные ими данные не были утекли из процесса Lambda куда-либо еще. Для этого, как минимум, третья сторона должна быть уверена, что функция Lambda не подключилась к какому-то другому ресурсу в Интернете и не слила на него данные.

При условии, что

  • Я предоставляю код, который будет работать с конфиденциальными данными
  • третья сторона не имеет возможности проверить этот код, и
  • третья сторона доверяет Amazon, но не доверяет мне

Есть ли способ добиться этого с помощью Lambda (возможно, в сочетании с другими продуктами AWS)? Я просмотрел решения, использующие шлюзы, EC2, шифрование в состоянии покоя, S3 и настраиваемые разрешения для всего этого, но не нашел решения.


amazon-s3 aws-lambda network-programming data-security
person mwag    schedule 03.05.2017    source источник
comment
Как отмечено в ответе ниже, функция Lambda внутри VPC может получить доступ к Интернету только в том случае, если вы настроите ее так, чтобы она могла, но поскольку вы контролируете среду, а вы контролируете код, это по-прежнему не служит доказательством того, что информация не просочилась. На самом деле, у вас никогда не будет возможности доказать мне, что вы не экспортировали/разоблачали/дублировали мои данные, если только у вас никогда не было к ним доступа. Иначе какое может быть техническое решение? Единственными возможными доказательствами будут аудиты доверенных третьих лиц.   -  person Michael - sqlbot    schedule 03.05.2017
comment
Я согласен с вашей оценкой, что приведенный ниже ответ не решает проблему из-за моего контроля над окружающей средой. Однако я не уверен, почему не может существовать техническое решение, если доверенная третья сторона предоставляет платформу, на которой работает код (и если предполагается, что доверенная сторона всегда выполняет свое обещание), чтобы гарантировать, что по запросу вызывающий, код выполняется в ограниченной среде.   -  person mwag    schedule 03.05.2017
comment
Кстати, в моем комментарии выше, когда я говорю о доверенной третьей стороне, я имею в виду AWS (в отличие от третьей стороны, которая предоставляет конфиденциальные данные и запускает код и которой нужны гарантии безопасности данных)   -  person mwag    schedule 03.05.2017

Ответы (2)


arrow_upward
1
arrow_downward

вы можете создать лямбда-метод внутри VPC и защитить его. прочитать это https://forums.aws.amazon.com/thread.jspa?messageID=733719 у них возникли проблемы, потому что они не могли получить доступ к Интернету

person UXDart    schedule 03.05.2017
comment
Как указывает @Michael в своем комментарии к OP, этот подход не решает проблему, потому что он все равно потребует, чтобы третья сторона доверяла мне не передавать данные (непреднамеренно или нет), поскольку я мог бы контролировать, будет ли / как VPC настроен. - person mwag; 03.05.2017
comment
Вы не можете дать им код и скрипт, который настраивает конфигурацию лямбда, и они запускают на нем свой VPC? Которому они могут доверять? - person johni; 03.05.2017
comment
Не идеально, так как я бы дал им код, который усложняет поддержку решения, но, тем не менее, это может быть лучшим возможным решением в настоящее время. +1 - person mwag; 04.05.2017

arrow_upward
1
arrow_downward

Единственное «доказательство», которое вы можете предложить, — это внешняя доверенная третья сторона (не AWS), которая провела аудит вашей среды, методов и политик и, к своему удовлетворению, уверена, что вы способны правильно обрабатывать конфиденциальные данные.

Клиент по какой-то причине не желает доверять вам обработку своих данных без одновременного просмотра некоторых из них без разрешения... в то же время вы, по-видимому, не хотите просто лицензировать свой код для них, чтобы они могли запускать его в среде, которая безопасно для их удовлетворения.

Ни то, ни другое не является технической проблемой. Это вопросы доверия.

Я не совсем уверен, что вы подумали о том, что на самом деле означает действительно изолированная среда. Очевидно, что вы не сможете обращаться ни к каким базам данных... но также обязательно будут лишены каких-либо функций ведения журнала. console.log(data.super_secret);. Журналы функций Lambda покидают среду Lambda и отправляются в CloudWatch.

Предполагая, что по какой-то причине вы не убеждены, всегда есть DNS-туннелирование . Прелесть этой зловещей схемы в том, что вы никогда не изолируетесь от разрешения DNS в VPC, даже если у вас нет интернета. Преобразователь DNS по адресу 169.254.169.253 всегда рядом, внимательно слушает, невосприимчив к группам безопасности, невосприимчив к сетевым ACL, невосприимчив к маршруту по умолчанию. Вы хотите тайком переправить данные из «изолированной» среды? Готово.

В любом случае AWS не гарантирует безопасность вашей конфигурации — они берут на себя ответственность только за безопасность своей инфраструктуры. Они заверяют вас, что он настолько безопасен, насколько вы его настроили... но то, как вы его настроите, зависит от вас. Они называют это моделью общей безопасности:

В то время как AWS управляет безопасностью в облаке, ответственность за безопасность в облаке лежит на клиенте. Клиенты сохраняют контроль над тем, какую безопасность они выбирают для защиты своего собственного контента, платформы, приложений, систем и сетей, точно так же, как и для приложений в локальном центре обработки данных.

введите здесь описание изображения

https://aws.amazon.com/compliance/shared-responsibility-model/< /а>

person Michael - sqlbot    schedule 03.05.2017
comment
Я проголосовал за, потому что вы поднимаете некоторые действительные вопросы (например, console.log). Тем не менее, я не уверен, почему трудно понять, почему клиент не будет доверять — многие банки и больницы еще даже не доверяют AWS или Google, поэтому, когда банки и больницы являются клиентами, предоставляющими конфиденциальные данные, это все еще скачок веры, чтобы предположить, что в конечном итоге им будет удобно доверять AWS / Google / Azure. Но это скачок, который гораздо легче сделать (отсюда готовность сделать это предположение здесь), чем если бы он был для любой компании (например, моей), кроме этих бегемотов. - person mwag; 04.05.2017
comment
Да, я понимаю, что это проблема доверия — цель этого вопроса — определить, можно ли решить эту проблему доверия между A и B с помощью технического решения, включающего взаимно доверенную сторону C — аналогично тому, как сертификаты SSL используют третья сторона (центр сертификации) для обеспечения уровня доверия, который невозможен без доверенной третьей стороны. - person mwag; 04.05.2017
comment
Я не собирался говорить или подразумевать, что трудно понять, почему клиент не доверяет поставщику. По какой-то причине был задуман как заполнитель для всего, от поставщика, который кажется схематичным, до клиента, который имеет нереально высокую оценку фактической ценности своих данных, изменить которую сложно и что-то среднее. - person Michael - sqlbot; 04.05.2017