タグ

awsとsecurityに関するmoqadaのブックマーク (10)

  • AWS セキュリティとコンプライアンス

    1. 2016 / 03 / 15 アマゾン ウェブ サービス ジャパン 株式会社 プロフェッショナルサービス部 高田 智己 【 AWS 初心者向け Webinar 】 AWSにおけるセキュリティとコンプライアンス 2. ご質問を受け付け致します! 質問を投げることができます! • Adobe Connect のチャット機能を使って、質問を書き込んで ください。(書き込んだ質問は、主催者にしか見えません) • 最後の Q&A の時間で可能な限り回答させていただきます。 ①画面右下のチャッ トボックスに質問を 書き込んでください ②吹き出しマークで 送信してください 3. AWS 初心者向け Webinar のご紹介 • AWS についてこれから学ぶ方むけの ソリューションカットの Webinar です • 過去の Webinar 資料 – AWS クラウドサービス活用資料集ページにて公開

    AWS セキュリティとコンプライアンス
  • もしもAWSでMFAが壊れて秘密の質問に答えられなかったら - Qiita

    Q.もしもAWSMFAが壊れて秘密の質問に答えられなかったら A.かなり面倒くさいし、10,000円以上かかる 概要 多要素認証(MFA)が利用できない状態になり、AWSのサポートに解除申請を出したところ、ピン番号の通知のあとに秘密の質問について聞かれた。登録したのがもう数年前で、しかもどうやら当時秘密の質問を適当に書いていたらしく、答えられなかった。そうすると、以下のようなものの提出を求められた。 免許証のコピー ガス・電気・水道等公共料金の領収書コピー 定形のフォーム(Word)に公証役場で私署証書の認証を受けた書面のコピー 上記をスキャンしてPDFにしてメールに添付して送れとのこと。 私の感想については以下のとおり。 マジか ガス・電気・水道は自動振込で領収書とかないはず Word持ってない 公証役場ってなんだ? 公証役場ってなんだ? 公正証書の作成や私的な書類の署名等が正しいとい

    もしもAWSでMFAが壊れて秘密の質問に答えられなかったら - Qiita
  • AWS Solutions Architect ブログ

    私たちは、新しくリリースされたPCIデータセキュリティ基準(PCI DSS)バージョン3.1に対する評価を完了し、2015年版のPCIコンプライアンスパッケージの提供準備が完了したことをお知らせします(なお、提供には、お客様からのリクエストが必要です)。PCI DSSは、重要なペイメントカードデータの処理やストレージ処理を含む、重要なワークロードをサポートするために使用される、世界的に認定されたセキュリティ規格です。 PCIコンプライアンスパッケージには、PCI DSSバージョン3.1の下で、レベル1サービスプロバイダの基準に対して検証が完了したことを証明する、AWS PCI準拠証明書(AoC)が含まれています。また、これには、AWSの独立した評価者による改訂と、お客様と200以上のPCI DSSコントロールのそれぞれにおいてAWSの責任共有モデルを説明する、拡張されたAWS PCI責任境

  • awsにおけるセキュリティ関連の認証、及び金融機関導入事例 - Qiita

    さて、セキュリティ的な立ち位置としての活動も開始したことだし、awsが取得しているセキュリティ関連の認証とか金融機関における導入事例をまとめてみるか。 詳細はawsのサイトにあるので、詳しく見たい方はawsのサイトを見たほうがいいですが、ざっくりと2016/01/17時点の情報を知りたい方に有用です。 サマリ 国内でも海外でも金融機関の導入事例がある(ただし、基幹システム含まず)。 セキュリティに関する認証や、品質に関する規格も数多く取得している。 寧ろ物理観点におけるセキュリティの基準は、日より海外の方が厳しいことや、論理と物理が疎結合となっているクラウドの特徴からかなり高いといえる。 awsが取得しているセキュリティ関連の認証 https://aws.amazon.com/jp/compliance/ にあるように、品質については以下の認証を取得している ISO 9001 : 製品と

    awsにおけるセキュリティ関連の認証、及び金融機関導入事例 - Qiita
  • AWSにおけるセキュリティの考え方

    機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ

    AWSにおけるセキュリティの考え方
  • AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita

    AWSアカウントを作成したら最初にやっておきたいことをまとめてみた。 あわせて読みたい 記事の内容を含めた最新の手順は、下記の書籍にまとまっている。 クラウド破産を回避するAWS実践ガイド AWSアカウント(ルートアカウント)の保護 AWSアカウントが乗っ取られると詰むので、真っ先にセキュリティを強化する。 AWSアカウントへ二段階認証を導入 AWSアカウントでのログインは、AWSアカウント作成時のメールアドレス・パスワードだけでできてしまう。心許ないにもほどがあるので、まずは二段階認証を設定しよう。 IAMのページを開く https://console.aws.amazon.com/iam/home 「ルートアカウントのMFAを有効化」を選択して、「MFAの管理」ボタンをクリック 「仮想MFAデバイス」にチェックが入っていることを確認し、「次のステップ」ボタンをクリック 注意書きを読ん

    AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita
  • 触って試す AWS MFA - 水深1024m

    相次ぐパスワードリスト攻撃もあり、いわゆる MFA (Multi-Factor Authentication) が使えるサービスが増えてきました。 AWS でもデバイスによる MFA ができるようになっています。 この仕組みとかについて書きます。 AWS について主に書いていますが他のサービスで使われているものも大体同じ (少なくとも GitHub とかは) はずです。 AWS MFA で使われている仕組み IAM の FAQ でも書かれていますが、 AWS で使うことができるのは TOTP (Time-based One-Time Password Algorithm) です。 アルゴリズムの説明は こちら などがわかりやすかったです。 TOTP の RFC もそんなに分量ないので読んでみると良いと思います。 ざっくり言うと TOTP がしているのはすごく単純なことで、 認証を行う側と認

    触って試す AWS MFA - 水深1024m
  • MyJVN APIを利用した脆弱性情報収集 | DevelopersIO

    はじめに 藤です。 のんのんびよりは二周目でも癒やされます。 概要 みなさん、ソフトウェアの脆弱性対応をどのように取り組んでいますか? ソフトウェアの多くには潜在的なバグが内在していて、そのバグ、脆弱性を利用されることでシステムが停止したり、情報を漏洩したり、最悪、システムが乗っ取られると言った様々なリスクを抱えています。これらのバグ、脆弱性の情報は様々な組織が運営する脆弱性情報データベースにより公開されることで私達は情報を知ることができます。ただ、脆弱性情報は多くのソフトウェアで小さいものから大きいものまであり、過去3ヶ月で1,790件(NVD検索結果)が報告されています。このように日々報告される情報から必要な情報を探すのは大変な労力を要します。 脆弱性データベース 有名な脆弱性データベースは以下のようなものがあります。 CVE(Common Vulnerabilities and E

    MyJVN APIを利用した脆弱性情報収集 | DevelopersIO
  • AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録

    AWS は Management Console や API ですべて操作できます(Direct Connect など一部例外もあります)。データセンターの物理的なセキュリティなどは AWS が責任を負うところで、ユーザーはまったく意識する必要はありません。 その代わり、OS やミドルウェアの管理、アプリケーションの設計や実装、適切な権限管理などはユーザーが責任を負うところです。 今回はあまり取り上げられないけど、すごく大事な権限管理についてまとめてみました。自分が仕事で関わっているプロダクトで権限管理を見直すときに調べたことをベースにしていますが、もっと良いプラクティスがあればぜひ教えてください。 AWS アカウントは使わない 普段の運用で AWS アカウントは使いません。 AWS アカウントとは、最初にサインアップするときに作られるアカウントです。 このアカウントは Linux で言う

    AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録
  • AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary

    情けない話ですが、自分の大チョンボで AWS の個人アカウントが第三者にアクセスされた結果 190万円相当のリソースが使われ、最終的に AWS さんに免除を頂きました。反省込みで件のまとめを書きます。 自分が馬鹿を幾つも重ねた結果であって、AWS 自体は怖くないというのが伝われば幸いです はじめにまとめ S3 実験してた時に SECRET KEY を見える場所に貼っていた事があり、第三者がそれでアクセスし大量の高性能インスタンスを全力で回す (恐らくBitCoin採掘) AWS さんから不正アクセスの連絡があり、急いで ACCESS KEY 無効&パスワード変更、インスタンス全停止、イメージ削除、ネットワーク削除 免除の承認フェーズを進めて、クレジットカードの引き落とし前に完了して助かる AWS さんのサポート AWS さんは最大限サポートしてくれました 承認フェーズが進まない時もあまり

    AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary
  • 1