はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは? DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
こんにちは、臼田です。 みなさん、インシデントの調査やっていますか?(挨拶 今回はオンラインで2020年6月16日より開催しているDevelopers.IO 2020 CONNECTにおいてAmazon Detectiveの紹介とガッツリデモを含んだ動画を公開したのでそちらを紹介します! 動画 解説 前置き スライドは最後尾に乗せています。が、デモの内容をバッサリカットしているので動画を見ていただくのが一番いいです。 今回は事前に収録できるということで、思う存分見せたい内容、伝えたい内容を乗せてみました。普段デモをやるのはけっこう大変なためやっていませんので、今回は私の中では珍しい内容です。 そして、お見せできないようなデータはモザイクをかけられるので、気にせず公開することができるのも動画投稿のいいところですね。 以下の内容は主に動画をこれから見る方向けです。 今回のコンセプト 2020年
クラウドワークス SREチームの @kangaechu です。アンタッチャブルのコンビ復活に目が離せないこの頃です。 クラウドワークス Advent Calendar 2019の4日目として、最近SREチーム内で使われるようになったツール、 aws-vault を紹介します。 背景 aws-vaultの話をする前に、少しだけAssumeRoleの話をします。 AssumeRole assumeは引き受けるなどの意味を持つ単語で、AWSを使用するユーザやリソースが本来持っている権限とは別の権限を引き受けることができるしくみです。ものすごいざっくりいうと、sudoコマンドのような感じです。AssumeRoleはどのようなときに便利なのでしょうか。 マルチアカウントでのIAMユーザ集約管理 リソースの分離や課金管理などを目的として、最近はAWS Organizationsを使用したマルチアカウン
企業や官公庁、団体のシステムを標的としたサイバー犯罪の手法は、多様化・高度化する一方だ。攻撃に負けない堅牢なセキュリティを実現するために、開発者の負荷は増え続けている。だが納期やリソースが限られた中で迅速に脆弱性を発見・修正するのは、もはや人手では対応しきれない。そこで注目を集めているのが、自動化されたセキュリティテストをDevOpsに組み込む「DevSecOps」だ。日本シノプシスの最先端IASTツール「Seeker」によるテストの自動化と、そのメリットについて吉井氏が語った。 講演資料:セキュリティ・テストの自動化によるDevSecOpsの実現 (デモ有) 日本シノプシス合同会社 ソフトウェア インテグリティ グループ シニア・セールス・エンジニア 吉井雅人氏 セキュリティテストを開発時に行いCI/CD連携を加速するDevSecOps 吉井氏は、「DevOpsとセキュリティの間には、越
コンテナのセキュリティについて、「これまで AWS 上でサービスを利用する上で通常考えていたセキュリティ」「コンテナワークロードを利用する上で考えるセキュリティ 」その二つの視点から、権限管理、ネットワーク、ログ・モニタリング、コンテナイメージ、その他、と、各トピックごとに Amazon Elastic Container Service (Amazon ECS) 、Amazon Elastic Kubernetes Service (Amazon EKS) それぞれでセキュリティを考えた場合に利用できる機能と設定方法などご紹介します。 Author: Fumihide NarioRead less
AWSのParameter StoreとSecrets Manager、結局どちらを使えばいいのか?比較AWSSecurityIAMSSM AWSのアクセスキー/シークレットアクセスキーのコード書き込みは危険 GitHubにAccess Key/Secret Access Keyを含むコードをPushしてしまい、 公開されたキーで犯罪者にAWS環境へのアクセスを許してしまい、 ハイスペックインスタンスタイプ(料金が高い)のインスタンスを 仮想通貨マイニング等に利用されてしまい、 請求書を見て青ざめる、 というインシデントが定期的に発生しています。 今年の2月にその危険性を検証された方がおられ、 「git pushから13分でご利用開始」とのこと。 GitHub に AWS キーペアを上げると抜かれるってほんと???試してみよー! - Qiita GitHubからアクセスキーを抽出するスクレ
GitHub、コードの脆弱性を発見してくれる「GitHub Code Scanning」発表、修正方法のアドバイスも。GitHub Satellite 2020 GitHubは、オンラインイベント「GitHub Satellite 2020」において、コードの脆弱性を発見してくれる新機能「GitHub Code Scanning」を発表しました。 Code scanning, powered by CodeQL, helps protect your code from vulnerabilities you might otherwise miss. #GitHubSatellite pic.twitter.com/8vGq3eFWPE — GitHub (@github) May 6, 2020 GitHub Code Scanningは、昨年買収したSemmleのソフトウェアを基にし
CommunityOpen SourceHow to build an effective DevSecOps cultureBy prioritizing secure development alongside speed, DevSecOps helps you ship safer applications by making security part of your current DevOps pipeline. DevOps, SecOps, now DevSecOps? While the DevOps we all know brings development and operations teams together, DevSecOps adds another process even high-performing DevOps teams can miss:
こんにちは、臼田です。 皆さん、AWS Config使ってますか? AWS Config自体は全てのユーザーが使っているサービスだと思います。各種リソースの設定変更を記録できて、例えば、いつどのようにSecurity Groupを変更したか、いつEC2を立ち上げたか、時系列で確認することができるので使わない手はないサービスです。弊社ではデフォルト有効化しています。 しかし、AWS Configに付属するサービスであるConfig Rulesはなかなか「みんなが使っている」というものではなかったです。 その理由はなんと言っても価格!1ルールあたり月額$2.00という決して安くない価格にありました。機能は良いんですけどね! でもそれが激安になるなら、話は別です。使いましょう、Config Rules! 今回新しいConfig Rulesの料金体系が発表されました! New – Updated
こんにちは、臼田です。 今回はre:Invent 2017で行われたSID218 - Introduction to Amazon GuardDutyについてレポートします。 自動セキュリティ分析サービスであるGuardDutyのデモや原理、具体的な活用方法について説明があり大変いい内容でした。 GuardDutyをきっちり理解したい人向けです。 レポート GuardDutyとは クラウドのために再考された脅威検知サービス AWSアカウントと、その内部で動作するアプリケーション・サービスを継続的に監視・保護する 既知・未知(ゼロデイ)の脅威を検出する AIとML(機械学習)を利用する 脅威情報(インテリジェンス)の統合 CloudTrail、VPC Flow Logs & DNSでの動作 詳細で対応可能な調査結果 筆者コメント: 簡単に表現すると、「ログを機械学習に突っ込んで役に立つ脅威情
2020年2月29日の技術書典8に発表予定だったAWSのアカウントセキュリティ本こと、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』の執筆が完了し、BOOTHで販売開始しました。 内容 書名のとおり、セキュリティがテーマです。そしてただのセキュリティを題材にすると、いろいろな方面からまさかりが飛んできそうなので、AWSのアカウントセキュリティと限定しています。で、アカウントセキュリティとはなんぞやという話ですが、前作ではAWSを扱う上での認証認可のサービスであるIAMをテーマにしていました。ここをしっかりしていると、ことAWSのアカウントまわりという点では6〜7割くらいはカバーできているのではと思っています。一方で、長く使っていると気が付かぬ穴や、複数人で使って誰かがやらかす人も出てくる可能性があります。この辺りを仕組みとしてカバーできるようにしようというのが、今回のアカ
はじめに IAMユーザを利用者へ引き渡す際に「絶対に多要素認証(MFA)の設定を入れてくださいね!!」と伝えても、 そのユーザが本当にMFAを有効化してくれたのか、その確認や催促に手間がかかるときがあります。 そんな手間を省くため、引き渡すIAMユーザには予め MFAを利用していないと権限に制限がかかる仕組みを仕込んでおくことができます。 概要 IAMユーザに以下の権限を付与すれば完了です。 (1) MFAを設定・有効化するための権限 (2) MFAを利用していない場合、(1)以外すべてのアクションを拒否する権限 (3) 本来許可したい権限 (2)の設定では、IAMポリシーのContdition要素を使ってMFA利用有無による条件分岐を設定します。 (3)で許可された権限であっても、 MFAを利用していない場合は(2)による明示的な拒否設定が上回り、利用することができなくなる仕組みです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く